Royaume du Maroc

Université Cadi Ayyad

Ecole Nationale des Sciences Appliquées de Marrakech
Année Académique 2009-2010

MEMOIRE DE PROJET DE FIN D’ETUDES

Pour l’obtention du diplôme de Master Réseaux et Systèmes
En
Génie Réseaux et Systèmes

Analyse, Conception et Mise en œuvre

d’une plateforme de contrôle à distance
à travers Internet pour assurer la
maintenance
Réalisé à

Réalisé par : Sous la direction de:

RURANGWA Elias Mr. Said Aghrib -MIC
Mr. JAKJOUD Abdeslam -MIC
Mr. Khalid EL BAAMRANI -ENSA
Devant le jury :
Mr Y. JABRANE - Professeur Assistant - ENSA de Marrakech
Mr L. GOUJDAMI - Administrateur - ENSA de Marrakech
Mr. S. AGHRIB - Directeur MIC Consulting group
Mr A. JAKJOUD - Ingénieur MIC Consulting Group
Mr K. EL BAAMRANI - Professeur Assistant - ENSA de Marrakech

Soutenu le : 29 Juin 2010

 Télémaintenance

Dédicaces

Je dédie humblement ce travail au gouvernement Marocain, à travers l’Agence

Marocaine de Coopération Internationale qui m’a octroyé une bourse de Master,
sans laquelle je ne pourrais pas continuer mes études.
Je dédie aussi ce travail à mes chers parents qui ont consacré les années de leurs
vies à m’éduquer, m’inculquer une bonne culture de travail et d’autosuffisance, à me
conseiller, ….. Aussi âgées qu’ils sont, ils veillent toujours sur moi et me donnent des
conseils qui font de moi du jour à jour un homme responsable.
Mes ainés Enias Ndahimana et Harindintwari Adiel m’ont supporté
financièrement et moralement le long de mes études. Je ne pourrais oublier leur
effort pour que chaque membre de la famille puisse mener une vie digne de soi.
Je remercie toutes les personnes qui m’ont aidé pendant la période de recherche
de stage notamment, Mr Afsahi Mohammed, qui n’a ménagé aucun effort pour que
je puisse trouver un stage. Il m’a beaucoup aidé dans mes choix et m’a nourrit de ses
multiples expériences dans le monde professionnel et personnel. Malgré que j’ai été
loin de ma famille, durant ces deux dernières années, j’ai été couvert d’un amour
inconditionnel de la famille du Pasteur Claude Massa, par son temps précieux, son
sens d’humour et d’extraverti, ses enseignements spirituels, ses conseils de toute
sorte, les repas que nous avons partagé en famille ou entre amis, et j’en passe. Il
m’a été un père, elle m’a été une mère.

Je n’oublierai pas tous mes amis qui m’ont supporté d’une manière ou d’une
autre durant ces deux dernières années notamment Sompassiti Charles, Benjamin
Baga, Aboubacar Ganemtoré, Ange Mwiseneza, Tuyishimire Pélagie, Sematuro
Lionel, Nshimiyimana François, Felix Nshimiyimana , Dieudonné Hirwa , Fiston
Rukundo Bruno, Jean de Dieu Gisa, Fabien Nshizirungu .
Et enfin, Kamarampaka Sauveur, mon ami et frère depuis 9 ans. Tant bien que
mal, nous avons vécus de bonnes expériences.
A vous tous, je vous dédie mon travail et j’aimerais vous dire que vous m’êtes
très chers.

ii
 Télémaintenance

Remerciements

En premier, merci à vous les membres du jury qui a accepté de juger ce

travail, je vous exprime ma plus sincère gratitude pour votre disponibilité et écoute
attentive.
Je tiens à remercier Pr. Khalid EL Baamrani, Professeur à l’Ecole Nationales
des Sciences Appliquées de Marrakech, qui m’a encadré le long de ce projet, par son
suivi, son aide et ses conseils, j’ai pu bien mener en terme ce projet. Je remercie
également Pr. Said Aghrib, mon tuteur et Directeur de MIC Consulting Group, qui
m’a accepté dans son entreprise et qui a veillé au bon déroulement de ce projet. La
réussite de mon projet a été possible grâce l’environnement conviviale et l’ambiance
sans égale qui règne au MIC Consulting Group, je remercie profondément tous les
membres de direction qui ont su mettre en place un tel climat et qui ont veillé à la
réussite de mon intégration.
Mon travail a aussi, grandement bénéficié du soutien et support qu’a pu
m’apporter tout le long de ce stage de fin d’études Mr. JAKJOUD Abdeslam,
Ingénieur et Etudiant en doctorat au Laboratoire de Technologie de l’Information et
Modélisation de l’Ecole Nationale des Sciences appliquées de Marrakech, je n’aurai
qu’un mot qui m’est cher à lui adresser, Merci.
A l’issue de deux dernières années au sein du département de Génie Réseaux
et Télécom de l’ENSA de Marrakech, j’adresse mes remerciements notamment à Pr.
Idboufker Noureddine, Responsable de notre formation, pour ses efforts pour que
notre formation soit une réussite et un tournant décisif dans notre vie, à Mr
Lhoussaine Goujdami, professeur dans ce département, par son temps précieux, n’a
réservé aucun effort pour le bon déroulement de notre formation, et enfin à toute
l’équipe enseignante pour la qualité de l’enseignement qui nous a été dispensé. Je
tiens à exprimer finalement ma reconnaissance à l’ensemble des personnes
impliquées, de près ou de loin, notamment les cadres et les ingénieurs de MIC
Consulting Group, pour rendre l’accomplissement d’un tel projet possible.

Merci.

iii
 ‫‪Télémaintenance‬‬

‫ملخص‬

‫الصٌانة عن بعد تتلخص فً القٌام بصٌانة النظم عبر شبكة معلوماتٌة مما ٌخول التحكم عن بعد بالحواسب من‬
‫أجل القٌام بعملٌات مخطط لها من خالل سٌاسة تسٌٌر‪ .‬وٌجب على هذه السٌاسة أن تخضع لدراسة جٌدة من أجل‬
‫عدم تعرٌض النظام ألي أضرار‪ .‬هذه األخٌرة قد تنتج عن عدم ضبط النظام‪ ،‬عن وجود فاٌروسات أو عن عدم‬
‫توافق بٌن النظام المادي و البرامج المعلوماتٌة‪ .‬الصٌانة اآللٌة عن بعد‪ ،‬على عكس الصٌانة التقلٌدٌة‪ ،‬ال تتطلب‬
‫اللوجستٌة المعقدة والمصارٌف الثقٌلة‪.‬‬

‫فً هذا التقرٌر نقدم لكم برنامج التحكم عن بعد عبر األنترنت مع كافة المعطٌات التً أدت إلى تصمٌمه‪ ،‬إضافة‬
‫إلى مجهود التشفٌر الذي تخضع له جمٌع االتصاالت الحرجة‪ .‬كما سنقدم لكم برنامج تجمٌع البٌانات الذي ٌتكلف‬
‫بدمج معطٌات قاعدة بٌانات فً أخرى ذات نفس التصمٌم‪.‬‬

‫الكلمات المفاتيح ‪.RMI, Socket, Scrum, JMF, LDAP, UML, BdD :‬‬

‫‪iv‬‬
 Télémaintenance

Abstract

The remote-maintenance is the distant maintenance through network. This helps

to take control of a remote computer in order to make operations following
management policy adopted. This policy must attentively be studied in order to
avoid the disturbance of the global system working.
In fact, the majority of bad-workings are based on configuration problems,
viruses, hardware and software dysfunctions .Contrary to the physical intervention,
the remote assistance does not need high and expensive logistics (movements,
schedules organization interventions circulation hazards, the mobilization of a
contributor by intervening.)
In this report, we present the platform of a remote control via the Internet that we
propose, and the methods which allows us to implement it; we also represent the
application which allows the aggregation of a database to another database which
has the same scheme.
And finally, in order to secure information passing through the Internet, we
incorporate in this platform the functions of encryption and decryption of the whole
critic traffic.

Key words: RMI, Socket, Scrum, JMF, LDAP, UML, Database.

v
 Télémaintenance

Résumé

La télémaintenance consiste en la maintenance à distance via le réseau. Ceci

permet de prendre le contrôle d’un ordinateur distant afin d’effectuer des opérations
suivant une politique de gestion adoptée. Cette politique doit être étudiée
minutieusement afin de ne pas compromettre le fonctionnement global du système.
En effet, la plupart des dysfonctionnements sont liés à des problèmes de
configuration, de virus, de conflits matériels ou logiciels. L’assistance informatique
en ligne contrairement à une intervention physique ne nécessite pas une logistique
lourde et couteuse (Déplacement, organisation des plannings d’interventions, aléas
de la circulation, mobilisation d’un intervenant par intervention).
Dans ce rapport, nous présentons la plateforme de contrôle à distance à travers
Internet que nous avons proposé ainsi que les méthodes qui nous ont permis de la
mettre en œuvre, nous proposons ensuite une application qui permet l’agrégation
d’une base de données vers une autre base de données ayant le même schéma et
enfin, pour assurer la sécurité des informations passant à travers Internet, nous
intégrons dans la plateforme les fonctions de chiffrement et de déchiffrement de tout
le trafic critique.

Mots clé : RMI, Socket, Scrum, JMF, LDAP, UML, BdD.

vi
 Télémaintenance

Sommaire
Dédicaces ...............................................................................................................................................................................ii
Remerciements ................................................................................................................................................................. iii
‫ ملخص‬........................................................................................................................................................................................iv
Abstract .................................................................................................................................................................................. v
Résumé ..................................................................................................................................................................................vi
Listes des figures ...............................................................................................................................................................ix
INTRODUCTION GENERALE ........................................................................................................................................1
Chapitre 1 : Contexte du projet ....................................................................................................................................2
1. Présentation de MIC Consulting .........................................................................................................................3
1.1. Présentation de MIC Consulting : ...................................................................................................................3
I.2 Une équipe pluridisciplinaire ............................................................................................................................3
I.3 Organisation interne de l’entreprise : ............................................................................................................3
2. La Problématique et objectif de la plateforme ............................................................................................4
3. solution proposée .....................................................................................................................................................5
4. Planification du projet ............................................................................................................................................7
Chapitre 2 : Etat de l’art et choix technologique ................................................................................................8
1. Gestion de projet.......................................................................................................................................................9
I.2 Scrum .....................................................................................................................................................................9
1.3 Idées clé des méthodes agiles. ....................................................................................................................9
1.4 Les différents acteurs du projet scrum ................................................................................................ 10
1.5 Processus de la gestion du projet scrum ............................................................................................ 11
2. Unified Modeling Language (UML) ................................................................................................................ 12
2.1 Les vues .............................................................................................................................................................. 12
2.2 Les diagrammes UML ................................................................................................................................... 13
3. Programmation réseau ....................................................................................................................................... 15
3.1 Les Sockets....................................................................................................................................................... 15
3.2 RMI (Remote method Invocation) .......................................................................................................... 17
3.3 Programmation Multimédia .................................................................................................................... 19
4. LDAP .......................................................................................................................................................................... 22
4.1 Le protocole LDAP ....................................................................................................................................... 23
4.2 Le modèle d’information............................................................................................................................ 23
4.3 Le modèle de nommage............................................................................................................................. 24
4.4 Le format LDIF .............................................................................................................................................. 25
4.5 Le modèle fonctionnel................................................................................................................................ 25
4.6. Le modèle de réplication........................................................................................................................... 26
4.7. Le modèle de sécurité ................................................................................................................................. 26
4.8 Apache Directory........................................................................................................................................... 27

vii
 Télémaintenance

Chapitre 3 : Analyse et Conception de la plateforme de contrôle à distance ......................................... 28

1. Introduction ............................................................................................................................................................ 29
2. Diagramme des cas d'utilisation ..................................................................................................................... 29
3. Authentification ..................................................................................................................................................... 30
4. Diagramme des séquences : Exécuter une commande .......................................................................... 30
5. Diagramme des séquences : Envoyer un fichier ....................................................................................... 31
6. Diagrammes des classes de conception ....................................................................................................... 32
6.1 Exécution d’une commande et enregistrer un fichier ................................................................... 32
6.2 Diagramme de classe pour les fonctions multimédia avec JMF ................................................. 34
6.3 Diagramme de classe de l’explorateur des fichiers ....................................................................... 35
6.4. Diagramme de classe : lancer une commande DOS ou une requête MYSQL. ..................... 35
7. Le module de messagerie instantanée......................................................................................................... 36
7.1 Diagramme de classe de l’application serveur ........................................................................ 36
7.2 Diagramme de classe de l’application Application cliente ......................................................... 37
8. Configuration du serveur LDAP...................................................................................................................... 38
8.1. Installation d’ApacheDS ............................................................................................................................. 38
8.2. Création d’une partition ............................................................................................................................. 38
8.3. Exemple de configuration du fichier LDIF .......................................................................................... 39
Chapitre 4 : Implémentation ...................................................................................................................................... 40
1. Introduction ............................................................................................................................................................. 41
3. Environnement de développement .............................................................................................................. 41
2. Scenario d’exploitation et vérification architecturale ............................................................................ 42
Chapitre 5: MICTopus.................................................................................................................................................... 51
1. Introduction ........................................................................................................................................................ 52
2. Premier Algorithmique .................................................................................................................................. 52
3. Deuxième Algorithmique .............................................................................................................................. 54
CONCLUSION ET PERSPECTIVE ............................................................................................................................ 55
Bibliographie..................................................................................................................................................................... 56
Glossaire ............................................................................................................................................................................. 57

viii
 Télémaintenance

Listes des figures

Figure 1 : Schéma Directeur de MIC Consulting Group .................................................. 4
Figure 2 : Le déplacement sur le lieu de maintenance ....................................................... 5
Figure 3: MIC et ses clients reliés par l’internet .................................................................. 6
Figure 4: Planification du projet. ........................................................................................... 7
Figure 5 : Le modèle de structure des acteurs de scrum ................................................. 10
Figure 6 : Le modèle de processus de Scrum. ................................................................... 11
Figure 7 : Diagrammes UML 2 ............................................................................................ 14
Figure 8:Hiérarchie des diagrammes. ................................................................................ 14
Figure 9 : socket, modèle OSI et modèle Internet. ............................................................ 16
Figure 10 : Communication des sockets. ............................................................................ 17
Figure 11 : Communication client/serveur ....................................................................... 18
Figure 12: Communication en couches RMI...................................................................... 18
Figure 13 : processus JMF ..................................................................................................... 19
Figure 14 : Enregistrement, le traitement et la présentation des médias temps réel. .. 20
Figure 15 : Architecture JMF ................................................................................................ 21
Figure 16 : Le système de transmission de média en utilisant JMF RTP. ...................... 21
Figure 17 : Entrée, attribue et valeur .................................................................................. 23
Figure 18 : Arbre LDAP. ....................................................................................................... 24
Figure 19 : Exemple d’un DIT. ............................................................................................. 25
Figure 20 : Exemple LDIF. .................................................................................................... 25
Figure 21 : Client/serveur LDAP en communication. ..................................................... 26
Figure 22: Apache Directory Studio. .................................................................................. 27
Figure 23 : Le diagramme de cas d’utilisation. ................................................................. 29
Figure 24 : Le diagramme de séquence d’exécution d’une commande......................... 31
Figure 25 : Le diagramme de séquence : envoyer un fichier. .......................................... 32
Figure 26 : Le diagramme de classe : exécuter une commande et enregistrer un
fichier. ...................................................................................................................................... 33
Figure 27 : Le diagramme de classe multimédia. ............................................................ 34
Figure 28 : Le diagramme de classe /arborescence des fichiers. ................................... 35
Figure 29 : Le diagramme de classe : envoyer une commande ou une requête SQL. 36
Figure 30 : Le diagramme de classe : les classes de messagerie coté serveur de
messagerie. ............................................................................................................................. 37
Figure 31 : Le diagramme de classe : les classes de messagerie coté client de
messagerie. ............................................................................................................................. 37
Figure 32: installation d’apacheDS. .................................................................................... 38
Figure 33 : Exemple d’un fichier ldif. ................................................................................. 39
Figure 34 : Exemple d’environnement de développement. ............................................ 42
Figure 35 : Système MIC. .................................................................................................... 42
Figure 36 : système client. .................................................................................................... 43
Figure 37: Plateforme de contrôle à distance(MIC). ......................................................... 43
Figure 38 : Connexion de l’utilisateur. ............................................................................... 43
Figure 39 : capture authentification .................................................................................... 44
Figure 40 : Autoriser la connexion LDAP. ....................................................................... 44

ix
 Télémaintenance

Figure 41:Demande d’assistance. ........................................................................................ 45

Figure 42 : communication 1. ............................................................................................... 45
Figure 43 : communication 2/ Assistance accepté. ......................................................... 45
Figure 44: Lancer une commande sur le serveur distant. ................................................ 46
Figure 45: capture de la commande ipconfig. ................................................................... 46
Figure 46: résultant de la commande ipconfig .................................................................. 47
Figure 47 : envoie d’un fichier. ............................................................................................ 47
Figure 48: Capture Envoie du fichier.................................................................................. 48
Figure 49 : Envoie du fichier réussi..................................................................................... 48
Figure 50 : communication audio-visuelle. ...................................................................... 48
Figure 51:capture des paquets audio-visuels .................................................................... 49
Figure 52 : Etablissement de connexion RMI. ................................................................... 49
Figure 53 : RMI se situe au dessus de la couche Transport. ............................................ 50
Figure 54 : Les données, chiffrement. ................................................................................. 50
Figure 55 : Algorithme brut proposé. ................................................................................. 53

x
Royaume du Maroc
Université Cadi Ayyad
Ecole Nationale des Sciences Appliquées de Marrakech
Année Académique 2009-2010

MEMOIRE DE PROJET DE FIN D’ETUDES

Pour l’obtention du diplôme de Master Réseaux et Systèmes
En
Génie Réseaux et Systèmes

Analyse, Conception et Mise en œuvre

d’une plateforme de contrôle à distance
à travers Internet pour assurer la
maintenance
Réalisé à

Réalisé par : Sous la direction de:

Mr. Said Aghrib -MIC
RURANGWA Elias Mr. JAKJOUD Abdeslam -MIC
Mr. Khalid EL Mr.
BAAMRANI -ENSA
Devant le jury :

Mr Y. JABRANE - Professeur Assistant - ENSA de Marrakech

Mr L. GOUJDAMI - Administrateur - ENSA de Marrakech
Mr. S. AGHRIB - Directeur MIC Consulting group
Mr A. JAKJOUD - Ingénieur MIC Consulting Group
Mr K. EL BAAMRANI - Professeur Assistant - ENSA de Marrakech

Soutenu le : 29 Juin 2010

 Télémaintenance

INTRODUCTION GENERALE

Le développement ultra-rapide des moyens modernes de communication et

de traitement de l’information permettent aux entreprises d’être à la fois plus
compétitives et de répondre rapidement aux besoins croissant de leurs clients. La
disponibilité et la réactivité étant un facteur important pour créer un climat de
confiance entre les entreprises de management des systèmes d’information et réseaux
d’une part et leurs clients d’une autre part, les entreprises de management des
systèmes d’informations et réseaux doivent non seulement tenir compte des
nouveaux besoins de leurs clients mais aussi ils doivent réaliser certaines tâches de
maintenance pour assurer la sureté de fonctionnement des systèmes gérés et ainsi
fidéliser leurs clients.
Dans cette optique, un budget important des entreprises incluant les frais de
déplacement et d’hébergement pour les clients situés relativement loin du siège, est
dédié aux taches de maintenances. En tenant compte de la mobilisation des
collaborateurs et consultants, la maintenance et l’évolutivité coûtent beaucoup aux
entreprises. D’où la nécessité de mettre en branle un projet de maintenance à distance
tout en assurant la sécurité des informations échangées par les différents acteurs
impliqués.
C’est ainsi que MIC Consulting Group, société de Management, Ingénierie et
Conseil, Leader national d’informatisation de l’état civil, s’intéresse à un tel projet
pour effectuer les diagnostiques et maintenances des serveurs de ses clients à travers
Internet et enfin, leur apporter l’assistance dans leurs activités.
Ce rapport est réparti en 6 chapitres principaux, le premier porte sur le contexte
du stage effectué au sein de la dite entreprise ainsi que la solution proposé pour
assurer la maintenance et l’assistance à distance à travers Internet. Le deuxième
chapitre traite les technologies et outils utilisés pour analyser, concevoir et enfin
pouvoir mettre en œuvre la solution proposé. Le troisième chapitre, quant à lui, met
le point sur la phase de conception et d’analyse, notamment certains diagrammes
UML sont mis en relief. Le quatrième chapitre comporte l’implémentation de la
plateforme et certains scénarios d’exploitation qui ont été élaborés. Enfin, dans le
souci d’améliorer la rapidité d’accès aux données et d’éviter la sous-exploitation de
ressources matérielles disponibles, le tout dernier chapitre intitulé MICTopus
présente la solution adoptée pour l’agrégation d’une base de données vers une autre
base de données ayant le même schéma.

1
 Télémaintenance

Chapitre 1 : Contexte du projet

Dans ce chapitre, nous nous contenterons de présenter l’entreprise

d’accueil, de traiter le sujet qui fait l’objet de notre stage, d’effectuer
une analyse des activités de maintenances et enfin, de cerner la
problématique chaînant des méthodes de maintenance actuelles tout
en proposant des solutions percutantes.

2
 Télémaintenance

1. Présentation de MIC Consulting

1.1. Présentation de MIC Consulting :

MIC Consulting Group, société créée en 2008, a été fondée par des chercheurs
dans les domaines : juridique, Management et informatique ainsi que les hommes
d’affaires. La volonté et la stratégie de MIC Consulting Group est d'intervenir dans
les domaines ci-haut cités avec une véritable différenciation et surtout de véritables
compétences tant techniques qu’humaines.
Les principales activités de MIC Consulting Group sont ci-après:
Etude Economique
Management et Ingénierie.
Conseil juridique et Fiscal.
Service d’Intérims.
Travaux de comptabilité.
I.2 Une équipe pluridisciplinaire

MIC Consulting Group dispose d’une équipe des chercheurs, consultants et

ingénieurs, confirmés dans leurs domaines respectifs, qui se réunissent pour former
un groupe de travail pluridisciplinaire, travaillant main dans la main pour atteindre
leur objectif.
Ayant développé une structure sans équivoque où toute personne a son mot à dire
sur les décisions et orientations de l’entreprise, MIC Consulting Group se distingue
par son souci de créativité et de recherche des solutions les mieux adaptées aux
besoins de ses clients.

I.3 Organisation interne de l’entreprise :

Le schéma ci-après décrit la hiérarchie de la société :

3
 Télémaintenance

Figure 1 : Schéma Directeur de MIC Consulting Group

Nous avons effectué notre stage dans le département d’ingénierie.

2. La Problématique et objectif de la plateforme

MIC Consulting Group dispose ses clients dans les différentes régions du Maroc,
plus particulièrement au sud. La maintenance de ces sites est assurée par ses agents
et consultants qui doivent se déplacer pour faire les différentes taches de conseils, de
mise en jour et de maintenance logicielle. Ces activités de maintenance dans les
régions sudistes sont estimées à 0.5 mois/homme chaque mois.
La figure 2 montre que pour atteindre les sites de leurs clients, les consultants ou
collaborateurs de MIC Consulting Group doivent se déplacer à chaque demande.
Le coût de maintenance, incluant le déplacement et les ressources humaines,
pèse sur l’entreprise qui, ayant privilégié la compétitivité et l’écoute de ses clients,
doit réagir et apporter des solutions adéquates à toute nouvelle demande et
suggestion.
L’objectif de la plateforme est de permettre aux consultants et collaborateurs de
MIC consulting Group d’assurer ces activités de maintenances et assistance à travers
Internet.

4
 Télémaintenance

Figure 2 : Le déplacement sur le lieu de maintenance

3. solution proposée
Pour optimiser les coûts de maintenances et vue que MIC Consulting Group
dispose le personnel compétant, pouvant suivre et maintenir un projet réseau, il
serait alors plus que profitable de mettre en branle un projet permettant la
maintenance à distance de ces sites. Ce projet apportera une amélioration qualitative
et quantitative dans la gestion des activités de maintenance et une assistance
pluridisciplinaire de ses clients, mais un certain nombre de contraintes doivent être
prise en compte pour assurer la sureté de fonctionnement et pour répondre aux
exigences des clients en terme de sécurité.

3.1 Gestion et maintenance

MIC Consulting Group gère les serveurs de ses clients et maintient leurs
applications. Pour ce faire, la plateforme doit accéder au système de fichiers des
serveurs Windows 2003/2008 avec les droits d'un administrateur. Certains fichiers
des serveurs pourront être supprimé, modifié ou remplacé.
La plateforme doit aussi permettre d'accéder aux SGBD installé sur ces serveurs.
La plateforme disposera un module audio-visuel pour assister et former les clients
dans leurs différentes tâches. Le client pourra envoyer un fichier ou un imprime
d'écran pour être analysé enfin de corriger les éventuels dysfonctionnements. Les
différents aspects d'accès au système doivent être appréhendés pour permettre un
contrôle total suivant les droits attribués.

5
 Télémaintenance

3.2 Sécurité
La sécurité est un élément plus qu’essentiel dans tout système informatique, plus
encore pour une application répartie à travers un réseau non fiable comme Internet.
Il est alors nécessaire de s'attaquer aux problèmes de sécurité réseau et système pour
prévoir les éventuels vulnérabilités et attaques afin d'implémenter une plateforme à
moindre risque de sécurité. L'aspect sécurité sera rigoureusement étudié et répondra
aux besoins évolutifs de la société. La figure 3 montre MIC et ses clients
interconnectés à travers Internet.

Figure 3: MIC et ses clients reliés par l’internet

Pour assurer le bon fonctionnement du système, nous préconisons alors

l’importance d’assurer au maximum la sécurité d’accès au système en intégrant les
trois techniques suivantes :

3.2.1. Authentification
Pour assurer la confidentialité des informations, une politique d’authentification
sera utilisée, on utilisera le protocole LDAP.

3.2.2. Journalisation
La plateforme permettra de retrouver les différentes tâches et manipulations
effectuées.

3.2.3. Chiffrage
Le trafic sera chiffré pour garantir une connexion et un transfert de trafic d'une
manière sécurisée. Pour cette partie, l'accent sera mis sur l'intégration et
encapsulation des différents algorithmes de chiffrement développé au sein de la
société.

6
 Télémaintenance

3.3. Ergonomie

Le système doit avoir un bon niveau d'ergonomie pour permettre une

manipulation rapide de certaines tâches répétitives. La gestion de l'historique de
certaines tâches sera envisagée.

3.4. Technologie

Le choix de la technologie appartient aux développeurs de la plateforme. MIC

Consulting Group souhaite que la technologie utilisé assure un bon niveau
d'utilisation de télémaintenance et d'ergonomie. Comme le choix de la technologie
nous incombe, nous choisirons par après une méthode de modélisation et un
langage de programmation assez robuste et facile à maintenir.

4. Planification du projet

Parmi les étapes cruciales pour conduire un projet et assurer une part de sa
réussite, se trouve la phase de planifier les tâches à accomplir et ordonnancer leur
déroulement afin d’estimer les délais à prévoir pour chaque tâche.
Tout en sachant que la phase de conception du système sera géré par la méthode
scrum, nus avons planifié notre projet comme le montre la figure 4.

Figure 4: Planification du projet.

7
 Télémaintenance

Chapitre 2 : Etat de l’art et choix

technologique

Dans ce chapitre, nous allons présenter les outils que nous avons
utilisés pour analyser, concevoir et mettre en œuvre la plateforme
de maintenance à distance. Au premier lieu nous avons géré notre
projet par la méthode scrum, une méthode agile permettant de
centrer tous les efforts sur le résultat attendu. Nous avons aussi
préféré utiliser une approche orienté objet, non seulement pour sa
réputation de maintenabilité et de réutilisabilité, mais aussi pour sa
riche documentation disponible; pour cela, le couple UML durant
toute la phase de modélisation et Java comme langage de
développement nous semble judicieux. Nous présenterons aussi,
certains concepts et libraires Java tel que RMI, JMF, sockets et par
après, nous montrerons un aperçu de LDAP, un annuaire très riche,
utilisé dans ce projet pour authentifier les utilisateurs.

8
 Télémaintenance

1. Gestion de projet

La réussite d’un projet est fortement liée à la manière avec laquelle il est géré,
plusieurs méthodes de gestions ont été proposées. Lors de ce projet, nous allons
utiliser la méthode scrum, une méthode agile qui nous permettra une gestion
collaborative le long de tout le cycle de vie de ce projet.

I.2 Scrum
Scrum est une méthode agile pour la gestion de projets. Les racines de Scrum se
retrouvent dans la publication de Takeuchi et Nonaka dans "The New New Product
Development Game" pour l'aspect métaphore du rugby ainsi que pour les notions
d'ingénierie concourante et dans la rupture méthodologique qualifiée d'itérative,
incrémentale et adaptative (par rapport au modèle cascade) dont la première version
opérationnelle a été publiée par James Martin en 1991 sous le nom de RAD, en ce qui
concerne sa structure fondamentale.
La méthode Scrum peut théoriquement s'appliquer à n'importe quel contexte ou à
un groupe de personnes qui travaillent ensemble pour atteindre un but commun
(comme des projets de recherche scientifique, projets informatiques ou planifier un
mariage).

1.3 Idées clé des méthodes agiles.

1. Le client au cœur du projet

Le client doit être impliqué dans le développement. On ne peut se contenter de
négocier un contrat au début du projet, puis de négliger les demandes du client. Le
client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation
du logiciel à ses attentes.

2. Esprit d’équipe
Dans l'optique agile, l'équipe est bien plus importante que les outils (structurants
ou de contrôle) ou les procédures de fonctionnement. Il est préférable d'avoir une
équipe soudée et qui communique, composée de développeurs (éventuellement à
niveaux variables) plutôt qu'une équipe composée d'experts fonctionnant chacun de
manière isolée.

3. La communication est la clé

La communication est une notion fondamentale dans un projet agile, la méthode
la plus efficace pour transmettre l'information est une conversation en face à face.

4. Simplicité, efficacité et qualité

Les méthodes agiles doivent centrer sur le concret, il est important de livrer
fréquemment une application fonctionnelle, toutes les deux semaines à deux mois,
avec une tendance pour la période la plus courte. On veille à ce que les équipes

9
 Télémaintenance

s’auto-organisent suivant les compétences de ces composants et du besoin du projet,

cette manière de procéder favorise une forte plus-value.

5. Flexibilité aux changements

La planification initiale et la structure du logiciel doivent être flexibles afin de
permettre l'évolution de la demande du client tout au long du projet. Les premiers
releases du logiciel vont souvent provoquer des demandes d'évolution.

6. Avancement basé sur le concret

Il est vital que l'application fonctionne. Le reste, et notamment la documentation
technique, est une aide précieuse mais non un but en soi. Une documentation précise
est utile comme moyen de communication. La documentation représente une charge
de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est
préférable de commenter abondamment le code lui-même, et surtout de transférer les
compétences au sein de l'équipe.

1.4 Les différents acteurs du projet scrum

Scrum définit trois rôles principaux : le directeur de produit, le ScrumMaster et
l'équipe. Des intervenants peuvent s'intégrer également au projet de façon plus
ponctuelle. Scrum utilise les valeurs et l'esprit du rugby. Comme le pack lors d'un
ballon porté au rugby, l'équipe chargée du développement travaille de façon
collective, soudée vers un objectif précis. Comme un demi de mêlée, le ScrumMaster
aiguillonne les membres de l'équipe, les repositionne dans la bonne direction et
donne le tempo pour assurer la réussite du projet.
Le schéma ci-après explique le processus de gestion d’un projet scrum ainsi que
les différents acteurs qui sont impliqués.

Figure 5 : Le modèle de structure des acteurs de scrum

10
 Télémaintenance

1.5 Processus de la gestion du projet scrum

La figure 6 montre la production d’une version du logiciel (release), ce qui se fait

en général en quelques mois. Les fonctionnalités demandées pour la release sont
collectées dans le backlog de produit et classées par priorité. Le propriétaire du
produit est responsable de l’insertion des changements dans ce backlog.

Figure 6 : Le modèle de processus de Scrum.

La réussite d’un projet scrum est centrée sur la communication entre les membres de
l’équipe, l’équipe doit tenir alors une réunion régulière et journalière ; lors de cette
réunion, chaque membre de l’équipe doit répondre à trois questions :
Qu'avez-vous fait depuis la dernière réunion?
Qu'allez-vous faire entre maintenant et la prochaine réunion?
il n'y a rien qui vous empêche de faire ce que vous avez prévu?
Les deux premières questions donnent aux participants de la réunion un aperçu
complet sur la façon dont le projet progresse. Quant à la troisième question fournit
des informations permettant de résoudre des problèmes matériels ou
organisationnels qui entravent l’avancement du sprint.
Notons que pour veiller à l’efficacité du scrum, tout le monde peut assister et
écouter lors de la réunion, mais seulement la Scrum Master et les membres de
l'équipe peuvent prendre la parole.
Scrum est un processus de développement de logiciels qui s'intéresse plutôt à
l'organisation du projet qu'aux aspects techniques. Son cadre de travail est sa force, si
bien que cette méthode pourrait être appliquée à d'autres domaines autres que les
applications informatiques. Son approche itérative et basée sur les besoins priorisés
du client lui confèrent une flexibilité extrême. Elle incarne bien par là l'état d'esprit de
la mêlée de rugby : avancer tous ensemble vers un but commun, la réussite du projet.
Scrum est un processus intéressant comme premier pas vers les méthodes Agiles :
il est facile à comprendre et à pratiquer. La seule difficulté relève plutôt de
l'environnement organisationnel.

11
 Télémaintenance

Remarque : Le long de ce projet, nous utiliserons l’outil open source IceScrum

qui couvre toutes les fonctionnalités de Scrum. IceScrum est une application J2EE qui
utilise largement Ajax pour permettre une utilisation de Scrum dans l'esprit d'un
espace de travail collaboratif.
Autre Méthode Agile : eXtrem Programming(XP).

2. Unified Modeling Language (UML)

UML est un langage de modélisation adopté et standardisé par Object

Management Group(OMG). Il se définit comme 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. UML est aujourd’hui un outil de
communication incontournable, utilisé sur des centaines de projets de par le monde.
Etant un langage de modélisation, UML permet de faire une représentation abstraite
d’un système réel ou non réel. Ses principaux objectifs sont :
Compréhension du système
Partage et communications des idées à propos du système entre les
différents membres d’une équipe.
Anticipation du fonctionnement du système avant sa réalisation.
Maîtrise de la complexité des systèmes.

UML se décompose en plusieurs sous-ensembles :

Les vues : Les vues sont les observables du système. Elles décrivent le système
d'un point de vue donné, qui peut être organisationnel, dynamique,
temporel, architectural, géographique, logique, etc. En combinant
toutes ces vues, il est possible de définir le système complet.
Les diagrammes : Les diagrammes sont des éléments graphiques. Ceux-ci
décrivent le contenu des vues, qui sont des notions abstraites. Les
diagrammes peuvent faire partie de plusieurs vues.
Les modèles d'élément : Les modèles d'élément sont les briques des diagrammes
UML, ces modèles sont utilisés dans plusieurs types de diagramme.
Exemple d'élément : cas d'utilisation (CU), classe, association, etc.

2.1 Les vues

Une des façons de mettre en œuvre UML est de considérer différentes vues qui
peuvent se superposer pour collaborer à la définition du système.
Les principales vues sont :
Vue des cas d'utilisation : c'est la description du modèle « vue » par les
acteurs du système. Elle correspond aux besoins attendus par chaque
acteur (c'est le QUOI et le QUI).
Vue logique : c'est la définition du système vu de l'intérieur. Elle explique
comment peuvent être satisfaits les besoins des acteurs (c'est le
COMMENT).

12
 Télémaintenance

Vue d'implémentation : cette vue définit les dépendances entre les

modules.
Vue des processus : c'est la vue temporelle et technique, qui met en
œuvre les notions de tâches concurrentes, stimuli, contrôle,
synchronisation, etc.
Vue de déploiement : cette vue décrit la position géographique et
l'architecture physique de chaque élément du système (c'est le OÙ).
2.2 Les diagrammes UML

Le langage UML 2 comporte 13 diagrammes ci –après:

Diagramme de classe : montre des briques de base statiques.
Diagramme d’objets : montre les instances des éléments structurels
et leurs liens à l’exécution.
Diagramme de package : montre l’organisation logique du modèle
et les relations entre packages.
Diagramme de structure composite : présente l’organisation
interne d’un élément statique complexe.
Diagramme des composants : montre des structures complexes,
avec leurs interfaces fournis et requises.
Diagramme de déploiement : montre le déploiement physique des
« artefacts » sur les ressources matérielles.
Diagramme de cas d’utilisation : montre les interactions
fonctionnelles entre les acteurs et le système à étudier.
Diagramme de vue d’ensemble d’interactions : fusionne les
diagrammes d’activités et des séquences pour combiner des
fragments d’interactions avec des décisions et des flots.
Diagramme de séquence : montre la séquence verticale des
messages passés entre objets au sein d’une interaction.
Diagramme de communication : montre la communication entre
objets dans le plan au sein d’une interaction.
Diagramme de temps : fusionne les diagrammes d’états et de
séquence pour montrer l’évolution de l’état d’un objet au cours du
temps.
Diagramme d’activités : montre l’enchainement des actions et des
décisions au sein d’une activité.
Diagramme d’états : montre les différents états et transitions des
objets d’une classe.

Nous pouvons répartir ces diagrammes suivant trois points de vue classiques de
modélisation comme le présente la figure 7.

13
 Télémaintenance

Figure 7 : Diagrammes UML 2

On peut aussi différencier les diagrammes suivant deux aspects : Diagrammes

structurelles et diagrammes comportementaux. La figure 8 décrit les diagrammes
UML sous cet aspect.

Figure 8:Hiérarchie des diagrammes.

14
 Télémaintenance

3. Programmation réseau
Les réseaux sont devenus une partie intégrante de notre vie quotidienne, nous
devons de plus en plus les utiliser pour exploiter au mieux des ressources
physiquement ou logiquement distinctes et automatiser les services qui
demanderaient autrefois des déplacements physiques. Dans notre cas nous voulons
développer une plateforme de contrôle à distance à travers le réseau Internet. Pour
cela, nous utiliserons le langage de programmation Java pour mettre en œuvre cette
plateforme. Le choix du langage Java nous a été facile non seulement parce que, c’est
un langage orienté objet qui permettrait une forte réutilisabilité mais aussi grâce aux
classes et interfaces déjà réalisées qui facilitent d’une façon remarquable la
programmation réseau autrefois studieuse. Et enfin, nous exploiterons la force de
Java pour son interopérabilité et portabilité.
Une des grandes forces de Java est de pouvoir travailler en réseau avec un haut
niveau d’abstraction, les concepteurs de la bibliothèque réseau de java en ont fait
quelque chose d'équivalent à la lecture et l'écriture de fichiers, avec la différence que
les « fichiers » résident sur une machine distante et que c'est elle qui décide de ce
qu'elle doit faire au sujet des informations que vous demandez ou de celles que vous
envoyez. Autant que possible, les menus détails du travail en réseau ont été cachés et
sont pris en charge par la machine virtuelle de java et l'installation locale de Java. De
plus, les fonctionnalités de multithreading de Java viennent à point lorsqu'on doit
traiter plusieurs connexions simultanées.

3.1 Les Sockets

Un socket est une abstraction de programmation représentant les extrémités d'une

connexion entre deux machines. Pour chaque connexion donnée, il existe un socket
sur chaque machine, on peut imaginer un câble virtuel reliant les deux machines,
chaque extrémité enfichée dans un socket. Nous pouvons définir alors un socket
comme une interface de programmation qui s’adapte aux différents besoins de
communication et regroupant l’ensemble de primitives nécessaire à cet effet. Dans
notre plateforme, les sockets seront utilisés pour mettre en œuvre l’application de
messagerie instantanée entre les clients et l’utilisateur de MIC Consulting Group. Le
package java.net permet de programmer facilement les sockets en TCP ou UDP.

3.1.1 Position des sockets dans le modèle OSI et modèle Internet

Les sockets se situent juste au-dessus de la couche transport du modèle OSI et au-
dessus de protocole de transport (TCP ou UDP) du modèle internet comme le montre
la figure 9 suivante :

15
 Télémaintenance

Figure 9 : socket, modèle OSI et modèle Internet.

3.1.2 Mode de communication

On distingue deux modes de communication entre les sockets:

Le mode connecté (comparable à une communication téléphonique),
utilisant le protocole TCP. Dans ce mode de communication, une
connexion durable est établie entre les deux processus, de telle façon
que l'adresse de destination n'est pas nécessaire à chaque envoi de
données.
Le mode non connecté (analogue à une communication par courrier),
utilisant le protocole UDP. Ce mode nécessite l'adresse de destination à
chaque envoi, et aucun accusé de réception n'est donné.

3.1.3. Choix de mode de communication

Nous utiliserons dans ce projet le mode de communication connecté. En effet le

protocole TCP, utilisé dans ce mode de communication, contient tous les atouts
nécessaire à l’établissement, au maintient et à la libération de connexion, ce qui nous
permettra de ne pas se soucier de certains détails de contrôle de flux et accès de
réception. En Java, on crée un objet Socket pour établir une connexion vers une autre
machine, puis on crée un inputStream et un OutputStream (ou, avec les
convertisseurs appropriés, un Reader et un Writer) à partir de ce Socket, afin de
traiter la connexion en tant qu'objet flux d'Entrées/Sorties.

Il existe deux classes Socket basées sur les flux : ServerSocket utilisé par un
serveur pour écouter les connexions entrantes et Socket utilisé par un client afin
d'initialiser une connexion. Lorsqu'un client réalise une connexion socket,
ServerSocket retourne un Socket correspondant permettant les communications du
côté serveur. À ce moment-là, on a réellement établi une connexion Socket à Socket et
on peut traiter les deux extrémités de la même manière, car elles sont alors
identiques. On utilise alors les méthodes getInputStream( ) et getOutputStream( )
pour réaliser les objets InputStream et OutputStream correspondants à partir de
chaque Socket. À leur tour ils peuvent être encapsulés dans des classes buffers ou de

16
 Télémaintenance

formatage tout comme n'importe quel objet flux. La figure 10 décrit la

communication des objets sockets.

Figure 10 : Communication des sockets.

Notons aussi que, comme nous vous avons signalé, pour faciliter la
programmation réseaux et des applications distribuées, plusieurs API ont été
développés facilitant la communication entre des objets. Ceci permet aux
programmeurs de se passer de certaines tâches de sérialisation, de contrôle,….Parmi
ces API nous utiliserons dans ce projet dans certains cas l’interface RMI (Remote
Method Invocation).

3.2 RMI (Remote method Invocation)

En général, un réseau est utilisé pour transmettre des données d'une extrémité à
l'autre. Cependant, on a besoin de transmettre parfois plus que des simples données
à l'état pur sur le réseau. C'est là que qu’on utilise les appels des procédures distant
RPC (Remote Procedure Calls). L’interface RMI est une version spécialisée de RPC
qui a été implémenté par Sun. Avec RMI différents objets peuvent interagir entre
eux, même s’ils ne sont pas sur la même machine virtuelle ou même s’ils sont sur
des ordinateurs différents.
RMI est alors une interface de programmation pour le langage Java qui permet
d'appeler des méthodes distantes. RMI définit un ensemble de classes permettant de
manipuler des objets sur des machines distantes (objets distants) ou sur la machine
locale (objets locaux). Notons bien qu’un objet distant pourrait être simplement un
objet se trouvant sur une autre machine virtuelle Java.
Caractéristiques de RMI:
RMI utilise beaucoup d'interfaces. Lorsque l'on souhaite créer un objet distant,
l'implémentation sous-jacente est masquée en passant par une interface. Ainsi,
lorsque qu'un client obtient une référence vers un objet distant, ce qu'il possède
réellement est une référence intermédiaire, qui renvoie à un bout de code local

17
 Télémaintenance

capable de communiquer à travers le réseau. On peut décrire une communication

RMI comme suit :
Le client utilise des interfaces d’objets implémentées coté serveur.
Quand un client appelle une méthode sur une telle interface, il le fait en
réalité sur un Stub (proxy)
Ce Stub transmet l’appel à la couche RRL qui assure la connexion avec le
serveur en point à point (unicast). Le rmiregistry travaille à ce niveau.
Cette couche transmet la requête à la couche transport qui utilise l’un des
protocoles JRMP (Java Remote Method Protocol) ou IIOP( Internet Inter-
Orb Protocol) au dessus de TCP/IP et transfère la requête en remontant
vers le skeleton qui appelle la méthode sur l’objet distant.

La figure 11 montre une communication du bout à bout des sockets, quant à la figure
12 décrit la communication verticale.

Figure 11 : Communication client/serveur

Figure 12: Communication en couches RMI.

18
 Télémaintenance

3.3 Programmation Multimédia

JMF (Java Média Framework) est une API (Application Programming Interface)
permettant l’intégration des média à forte contraintes du temps dans des applications
et des applets Java.
JMF prend en charge la capture des médias et répond aux besoins des
développeurs d'applications qui veulent un traitement et un contrôle
supplémentaire sur les médias. Il fournit également une architecture plug-in
permettant d'accéder directement aux données des médias. Notons aussi que JMF est
facilement personnalisable.

3.3.2 Les avantages de JMF

Parmi tant d’autres avantages de JMF nous pouvons citer ceux qui suivent :
Architecture et concept facile à maitriser.
Fournit des interfaces pour la capture des médias
Permet le développement de médias en streaming et des applications de
vidéoconférence en Java.
Permet aux développeurs avancées et fournisseurs de technologie de
mettre en œuvre des solutions personnalisées basées sur JMF et
d'intégrer facilement de nouvelles fonctionnalités selon leur besoins.
Permet d’accéder aux données bas niveau des médias
intègre plusieurs concepts multimédia le multiplexage, démultiplexage,
des codecs.

Toutes les données temps réel se différencient des autres par la prise en compte
de contraintes temporelles dont le respect est aussi important, les données doivent
être délivrées dans des délais imposés. La voix, les clips audio, les clips et les
animations sont des formes courantes de médias basés sur le temps. Ces supports de
données peuvent être obtenues auprès de diverses sources, telles que les fichiers du
réseau local ou, caméras, microphones, et des émissions en direct, … Le schéma ci-
dessous (Figure 13) montre les états d’un flux temps réel :

Figure 13 : processus JMF

19
 Télémaintenance

3.3.3 Architecture de JMF

JMF fournit un protocole et une architecture unifiée pour gérer l'acquisition, le

traitement et le transport des données temps réels. JMF supporte la plupart des
types de médias standard, tels que AIFF, AU, AVI, GSM, MIDI, MPEG, QuickTime,
RMF, et WAV.
Notons aussi qu’une application développée avec JMF peut être exploité sur
n’importe quelle plateforme ayant une machine virtuelle Java d’où son énorme
portabilité.
Des appareils tels que lecteurs de cassettes et magnétoscopes fournir un modèle
familier pour l'enregistrement, le traitement et la présentation des médias temps réel.
Lorsque nous lisons un film à l'aide d'un magnétoscope, nous fournissons un flux
média au magnétoscope en insérant une cassette vidéo. Le magnétoscope lit et
interprète les données sur la bande et envoie les signaux appropriés à votre
téléviseur et haut-parleur.

Figure 14 : Enregistrement, le traitement et la présentation des médias temps réel.

JMF utilise ce même modèle de base. Une source de données encapsule le flux
média un peu comme une cassette vidéo et un lecteur de traitement fournit des
mécanismes de contrôle similaires à un magnétoscope. La capture audio et vidéo
avec JMF exige l'entrée et de sorties appropriées tels que des microphones, caméras,
haut-parleurs et les écrans.
Pour cela JMF API utilise « Data sources » et « players » pour gérer la capture, la
présentation et le traitement des médias temps réel. JMF fournit également une API
de bas niveau qui prend en charge l'intégration d’une manière transparente des
composants et extensions personnalisé.
Le schéma ci-après (Figure 15), montre l’architecture d’une application ou applet
JMF et les différentes possibilités qu’il offre.
On distingue deux types de flux média suivant la façon dont les données sont
fournies :
Pull : Le transfert de données est initié et contrôlée à partir du côté client.
Exemple : HyperText Transfer Protocol (HTTP), Fichier(FILE), ….

20
 Télémaintenance

Push : le serveur lance le transfert de données et contrôle le flux de données. Par

exemple, Real-time Transport Protocol (RTP) est un protocole utilisé pour le
transport des streaming et les flux temps réel. De même, le protocole SGI MediaBase
est un protocole utilisé pour le transport de la vidéo sur demande (VOD).Notons que
dans ce projet nous utiliserons le protocole RTP.

Figure 15 : Architecture JMF

3.3.4 Le système de transmission de média en utilisant JMF RTP

Le système qui transmet les paquets RTP est un système client/serveur, cela se
compose d'un module d'émetteur et d'un module de récepteur. Le système a été
développé en utilisant Java API JMF.
L'émetteur transmet les données et le récepteur les reçoit. La figure 16 montre le
processus global d'un procédé de transmission de médias en utilisant RTP. La
transmission par RTP est reportée par des sessions. Une fois que l'émetteur est prêt
pour la transmission de données, une session de RTP est crée pour transmettre le
flux de données.

Figure 16 : Le système de transmission de média en utilisant JMF RTP.

21
 Télémaintenance

3.3.4.1 Les classes Emetteurs/Récepteurs de Média

Le module de réception est composé par :

Le SessionManager() est une classe qui reçoit une adresse IP et
l’argument de numéro de port, coordonne une session de RTP et peut
avoir de divers auditeurs(listeners) supplémentaires.
Les flux dont le SessionManager s'occupe peuvent être l'un de deux
types :ReceiveStream ou SendStream.
Dans le système développé, le récepteur écoutent dehors l'événement
de NewReceiveStream, qui obtient activé toutes les fois qu'une nouvelle
transmission se passé ou quand le DataSource se produit.
DataSource et un objet que transmet ou reçoit les données, liées au flux
obtenu.
Le player inclut de deux types - contrôleur et processeur. Le player de
contrôleur prend des données de son DataSource et présente ceci
comme la voix et le player de processeur extrait les données de médias
à partir du fichier ou à partir du capture media pour la transmission.

3.3.4.2 Emetteur de média

Pour l'émetteur, les données de médias sont extraites à partir des fichiers au
moyen d'un processeur. Le processeur est employé pour analyser les médias et
permettent d'opérer sur contenu facilement.Une fois que le fichier de données est
disponible, il est alors passé à un RTP SessionManager, qui manipuler le flux de
transmission. Le module d'émetteur de médias a des méthodes spécifiques qui
exécutent diverses fonctions pour transmettre le flux de données qui est reçu par le
récepteur.

3.3.4.3 Récepteur de média

Dans le module de récepteur, le SessionManager reçoit le flux de données du

réseau qui était transmis par l'émetteur. Une fois le SessionManager commence
recevoir le flux de données, le DataSource est employé pour placer et stocker les
données et le player sont activés. Le récepteur décode le flux de données audio
transmis. Le module de récepteur de médias emploie un objet de Controller Player.

4. LDAP
LDAP (Lightweight Directory Access Protocol) est un protocole d'accès à un
annuaire, dérivé d' X500, au dessus de TCP/IP. C'est une implémentation allégée du
protocole ISO DAP. Il est devenu le standard des annuaires électroniques qui
prennent de plus en plus d'importance dans les systèmes d'information des
entreprises.
LDAP définit :
un protocole permettant d’accéder à l’information contenue dans
l’annuaire,
un modèle d’information définissant le type des informations
contenues dans l’annuaire,

22
 Télémaintenance

un modèle de nommage définissant comment l’information est

organisée et référencée,
un modèle fonctionnel qui définit comment accéder à l’information
(syntaxe des requêtes, .. .),
un modèle de sécurité qui définit comment les données et accès sont
protégés,
un modèle de duplication définissant comment la base est répartie
entre serveurs,
des API pour développer des applications clientes,
LDIF, un format d’échange de données.

4.1 Le protocole LDAP

Le protocole LDAP définit comment s'établit la communication client-serveur. Il
fournit à l’utilisateur des commandes pour se connecter ou se déconnecter, pour
rechercher, comparer, créer, modifier ou effacer des entrées. Des mécanismes de
chiffrement (SSL ou TLS) et d'authentification (SASL), couplés à des mécanismes de
règles d'accès (ACL) permettent de protéger les transactions et l'accès aux données.

4.2 Le modèle d’information

LDAP définit le type des données pouvant être stockées dans l’annuaire. L'unité
de base de l'information stockée dans le répertoire est appelé une entrée(Entry). Les
entrées représentent des objets (réel ou abstrait) ayant l’intérêt dans le monde réel,
comme les personnes, les serveurs, organisations, et ainsi de suite. Les entrées sont
composées d'une collection d'attributs décrivant les caractéristiques de l’objet.
Chaque attribut a un type et un ou plusieurs valeurs. Le schéma de l’annuaire définit
la liste des classes d’objets qu’il connaît. Le Directory schema est la « charte » qui
donne, pour le serveur, l’ensemble des définitions relatives aux objets qu’il sait
gérer.
Le schéma décrit les classes d’objets, leurs types d’attribut et leur syntaxe. Chaque
entrée de l’annuaire fait obligatoirement référence à une classe d’objet du schéma et
ne doit contenir que des attributs qui sont rattachés au type d’objet en question. La
relation entre une entrée de l’annuaire LDAP et de ses attributs et leurs valeurs des
attributs est illustrée à la figure 17.

Figure 17 : Entrée, attribue et valeur

23
 Télémaintenance

Un attribut est défini par un nom, un identifiant unique (OID), mono/multi

valeurs, une syntaxe et des règles de comparaison (matching rules), une valeur
(format+taille limite), modifiable ou non.

Les classes d’objet modélisent des objets réels ou abstraits comme un compte
UNIX (posixAccount), une organisation (o), un département (ou), un personnel
(organizationPerson), une imprimante (device),. . .

Une classe d’objet est définie par un nom, OID, des attributs obligatoires, des
attributs optionnels, un type (structurel, auxiliaire ou abstrait).

Notons que l’objet père de tous les autres est l’objet top comme le montre la
figure 18.

A.

Figure 18 : Arbre LDAP.

4.3 Le modèle de nommage

Le modèle de nommage LDAP définit la façon dont les entrées sont organisées et
comment elles sont référencées. Les entrées sont organisées dans une structure
arborescente appelée DIT ( Directory Information Tree). La Structure arborescente
contient deux catégories d’objets :
les conteneurs : départ d’une nouvelle branche (nœud intermédiaire de
l’arbre)
o peuvent contenir des conteneurs ou des feuilles
o généralement, une sous-organisation de l’organisation (zone
géographique,. .)
les feuilles : elles représentent les données (généralement les machines,
les utilisateurs,. . .).
Chaque entrée est référencée de manière unique dans le DIT par son distinguished
name (DN). Le DN représente le nom de l'entrée sous la forme du chemin d'accès à
celle-ci depuis le sommet de l'arbre. On peut comparer le DN au path d'un fichier
Unix. Par exemple, le DN correspondant à l'arbre de la figure 19 est :

Uid=toto,ou=people,dc=labri,dc=fr

24
 Télémaintenance

Figure 19 : Exemple d’un DIT.

4.4 Le format LDIF

LDIF : LDAP Interchange Format définit un format standardisé de représentation

des entrées sous format texte.
LDIF Permet de :
faire des imports/exports de la base ou d’une partie de la base
créer, ajouter, modifier un grand nombre d’entrées de manière
automatisée. La figure 20 présente un exemple de fichier ldif.

Figure 20 : Exemple LDIF.

4.5 Le modèle fonctionnel

LDAP décrit le moyen d’accéder aux données (syntaxe des requêtes) et les
requêtes que l’on peut leur appliquer. Ce modèle est composé de trois catégories
d'opérations :
Connexion au service: bind, Unbind, abandon.
Intérrogation: Search, compare.
Mise à jour: add, delete, modify, rename.

La figure 21 montre la communication d’un client et un serveur LDAP ; le client

ouvre une session sur le serveur LDAP et lance des requête d’interrogation ou de
mise à jour jusqu’à l’abandon de la session.

25
 Télémaintenance

Figure 21 : Client/serveur LDAP en communication.

4.6. Le modèle de réplication

Ce modèle définit comment dupliquer l’annuaire sur plusieurs serveurs. Ceci

permet :
d’améliorer le temps de réponse.
d’être tolérant aux pannes.
Il existe deux types de serveurs LDAP :
supplier server: fournit les données.
consumer server: reçoit les données du maître.

Ce modèle permet aussi la possibilité de partitionner l’annuaire (éclatement sur

plusieurs serveurs) et ainsi que des liens virtuels entre les différentes partitions.

4.7. Le modèle de sécurité

Il définit les mécanismes d'authentification et de droits d'accès des utilisateurs à
l'annuaire.
a. Authentification
LDAP propose plusieurs choix d'authentification :
anonymous authentification correspond à un accès au serveur sans
authentification, qui permet uniquement de consulter les données
accessible en lecture pour tous.
Root DN Authentication correspond à l'utilisateur privilégié. Il a accès
en modification à toutes les données.
mot de passe en clair : c'est la méthode classique où le mot de passe
transite en clair sur le réseau.
mot de passe + SSL ou TLS : la session entre le serveur et le client est
chiffrée et le mot de passe ne transite plus en clair.
certificats + SSL- Simple Authentification and Security Layer (SASL) :
permet de faire appel des mécanismes d'authentification plus élaborés à
base de clés (OTP, Kerberos...).

26
 Télémaintenance

b. Contrôle d'accès
Il s'agit de définir les droits d'accès des utilisateurs sur les ressources de
l'annuaire.

Le long de ce projet, nous avons utilisé le serveur LDAP Apache Directory Service
et le client LDAP Apache studio.

4.8 Apache Directory

Apache Directory est un projet libre de la fondation Apache. Son principal

composant, Apache Directory Server, est un serveur d’annuaire LDAP
« embarquable » écrit en Java. Il a été certifié compatible LDAPv3 par l’Open
Group en 2006. Au-delà de LDAP, le serveur prend également en charge d’autres
protocoles, et inclut un server Kerberos.
Nous avons aussi un sous-projet Apache Directory Studio proposant un outil,
basé sur Eclipse, pour gérer un annuaire. Celui-ci inclut un navigateur et éditeur
LDAP, un navigateur de schéma, un éditeur LDIF et DSML, et plus encore. Cet outil
est disponible sous la forme de plugins Eclipse ou d'application autonome RCP. La
figure 22 est l’interface graphique d’Apache Directory, elle permet d’accéder aux
services d’annuaire avec une réelle simplicité. Les opérations d’importations et
d’exportation des fichiers en plusieurs formats, notamment, en format ldif sont
prises en charge.

Figure 22: Apache Directory Studio.

27
 Télémaintenance

Chapitre 3 : Analyse et Conception de la

plateforme de contrôle à distance

Ce chapitre concerne l’analyse et conception du sujet ; certains

digrammes UML de la plateforme seront représentés, nous
expliquerons aussi la configuration du serveur de LDAP
permettant aux utilisateurs de s’authentifier.

28
 Télémaintenance

1. Introduction
Cette partie concerne l'analyse des besoins fonctionnels, le fonctionnement
dynamique et statique de l'application. Le modèle UML est utilisé pour l’analyse et la
conception, les différents diagrammes de cas d’utilisation, de séquences et les
diagrammes de classes seront présentés.

2. Diagramme des cas d'utilisation

Ce diagramme de cas d'utilisation va nous donner un aperçu global de toutes les
fonctionnalités basiques de la plateforme. Nous avons relevé 4 acteurs distincts
comme le montre la figure 23:

1) un utilisateur MIC: un utilisateur MIC a le droit aux fonctionnalités avancées

de la plateforme à savoir: Accès au système distant, exécution des commandes
DOS et MYSQL, l'arborescence des fichiers avec les droits d'administrateur,
envoyer un fichier,.....
2) Un utilisateur client: Cette utilisateur désigne un utilisateur du site distant, qui
peut seulement envoyer un fichier ou initier un appel pour demander une
assistance.
3) Système client: Le système d'exploitation distant.
4) Système MIC: Le système d'exploitation MIC.

Figure 23 : Le diagramme de cas d’utilisation.

29
 Télémaintenance

Ces 4 acteurs vont interagir avec le système composé par deux applications:
Une application serveur permettant d'accéder aux objets distants.
un client lourd utilisant les objets distants.
3. Authentification
La première phase de notre plateforme est l’authentification. Un utilisateur de
MIC voulant effectuer une quelconque opération sur la plateforme doit
s’authentifier auprès de serveur LDAP, il ne pourra effecteur l’opération que si son
niveau d’accès lui permet d’accéder à la plateforme. Ceci nécessite d’interfacer la
plateforme et le serveur LDAP. Notons aussi que l’authentification est centralisée sur
le serveur situé à MIC Consulting Group. Le client distant ne pourra lui aussi utiliser
la plateforme qu’après s’avoir été authentifié au serveur LDAP de MIC, le login et le
mot de passe sont envoyés à l’application d’authentification, Si son authenticité est
approuvée, l’application lui autorise de se connecter sur l’application de contrôle
client distant, autrement l’accès lui est refusé et le client ne pourra accéder à la
plateforme.
Après l’authentification, l’utilisateur MIC ou client pourra effectuer plusieurs
opérations, suivant son niveau d’accès, à savoir : exécuter une commande, envoyer
un fichier, …Les diagrammes de séquences des certaines opérations offertes par la
plateforme seront présentés ci-après.

4. Diagramme des séquences : Exécuter une commande

La prise de contrôle à distance ou la télémaintenance permet d’accéder à une
machine distante, sans ou avec l’autorisation préalable, pour la maintenir. Nous
procédons d’bord par l’envoie des commandes DOS ou requêtes MYSQL qui seront
exécuté par la machine distante et fin retournant le résultant.
a. Envoie de commande DOS ou requête MYSQL

Une commande est exécutée par un utilisateur MIC ayant les droits d’exécuter
une commande sur le serveur distant. Le scénario commence par l’authentification
de l’utilisateur. Celui-là, une fois authentifié, il peut saisir une commande ou une
requête, le système chiffre la commande ou la requête saisie avant d’être envoyé sur
le réseau internet vers le serveur distant. Le système distant reçoit la requête ou la
commande chiffrée, puis il la déchiffre et enfin, l’exécute sur le serveur distant.
b. Lé résultant de la commande

Le résultant de la commande chiffré est envoyé par l’application se trouvant sur le

serveur distant à travers l’internet vers le system MIC qui, à son tour, le déchiffre
pour afficher le résultant à l’utilisateur de MIC.
La figure 24 présente le diagramme de séquence d’exécution de la commande ou
requête MYSQL prenant l’enchainement expliqué ci-haut.

30
 Télémaintenance

Figure 24 : Le diagramme de séquence d’exécution d’une commande.

5. Diagramme des séquences : Envoyer un fichier

La plateforme permet, à l’utilisateur MIC ayant le droit, d’envoyer des fichiers sur
le serveur distant. Le fichier avant d’être envoyé est chiffré et une fois sur le serveur
distant, il est déchiffré et enfin stocké sur le serveur. La figure 26 montre le
digramme de séquence illustrant les étapes d’envoi d’un fichier sur le serveur
distant.

31
 Télémaintenance

Figure 25 : Le diagramme de séquence : envoyer un fichier.

6. Diagrammes des classes de conception

Au premier lieu nous allons concevoir les diagrammes de classe de
l’application situant au serveur distant et permettant d’accéder à ses ressources.

6.1 Exécution d’une commande et enregistrer un fichier

La partie exécution de commande et enregistrer un fichier illustré par le
digramme de classe de conception de la figure 26 est l’une des parties importante de
la plateforme de contrôle à distance, ce diagramme de classe regroupe deux
fonctionnalités de base : Lancer des commandes et enregistrer des fichiers.

Ce diagramme de classe de conception utilise RMI. Dans une application RMI,

on définit d’abord des interfaces qui seront invoquées lors des appels par une
application distante, ses interfaces dérivent de l’interface java.rmi.Remote. Les
classes implémentant ces interfaces distantes dérivent eux aussi de la classe
java.rmi.server.UnicastRemoteObject. De plus les méthodes de ces classes doivent
pouvoir lancer une exception de type java.rmi.RemoteException. Des instances de

32
 Télémaintenance

ces classes seront exécutées dans la classe serveur et enregistré dans un registre
rmiregistry, ce qui permettra à un programme client distant de pouvoir y accéder.

Figure 26 : Le diagramme de classe : exécuter une commande et enregistrer un fichier.

a. Commande
Une commande peut être une commande DOS pour les serveurs Windows ou des
requêtes MYSQL qui permettent d’accéder au serveur de base de données MYSQL.
La connexion à la base de données se fait une fois par le patron de conception
(design pattern) singleton « SingletonConnection ».
Les fonctionnalités de chiffrement et de déchiffrement sont encapsulées dans
design pattern singleton SingletonCypher.
Nous avons préféré utiliser le design pattern singleton pour pouvoir contrôle le
nombre des instances exécutés, particulièrement pour pouvoir avoir une instance
unique au moment de l’exécution du programme serveur.

b. Fichier
Cette interface définit toutes les fonctionnalités permettant d’enregistrer dans un
répertoire donnée un fichier envoyé par le client sur le serveur.

33
 Télémaintenance

c. Chiffrage
Il est important de signaler que la classe SingletonCypher encapsule les
fonctionnalités de chiffrement et de déchiffrement fournit par l’interface Chiffrage;
en effet tous les flux d’informations que le serveur reçoive sont chiffré et seront
déchiffré par celui-là, de retour, tous les flux d’informations que le serveur envoie
seront chiffrés. Nous avons pour cela utilisé la librairie de chiffrage développée au
sein de MIC Consulting Group.

6.2 Diagramme de classe pour les fonctions multimédia avec JMF

Le diagramme illustré par la Figure 27 contient toutes les fonctionnalités d’une

application média permettant d’envoyer et de recevoir comme cité dans la partie
théorique un flux audio et vidéo avec le protocole RTP/RTCP en utilisant JMF. Dans
notre cas, l’application émettrice capture un flux audio et/ou vidéo, le code, enfin
l’envoie avec RTP sur le réseau à l’adresse IP de l’application de destination, cette
dernière reçoit le flux, le décode, le met en format approprié et elle l’affiche ou le lit
sur la sortie standard. Pour plus de détails veillez lire le chapitre II, la partie dédiée à
JMF émetteur/récepteur.

Figure 27 : Le diagramme de classe multimédia.

34
 Télémaintenance

6.3 Diagramme de classe de l’explorateur des fichiers

L’explorateur de fichier (Figure 28) permet d’ouvrir l’arborescence des fichiers se

trouvant sur le serveur à contrôler. Notons que nous n’avons pas chiffré cette objet
d’où sa restriction d’utilisation, et son intérêt limité qu’à la lecture seule.

Figure 28 : Le diagramme de classe /arborescence des fichiers.

Nous avons omis volontairement dans ce rapport toutes les méthodes triviales, tel
que les méthodes GET et SET, ainsi que les autres méthodes élémentaires.
Le module d’authentification qui est développé permet d’accéder au serveur
LDAP installé sur le système MIC. Les diagrammes de classes ci-haut mentionnés
concernent l’application serveur. Nous allons montrer par après, certaines classes de
l’application cliente (l’application qui contrôle
6.4. Diagramme de classe : lancer une commande DOS ou une
requête MYSQL.

Ce diagramme de classe (Figure 29) montre l’exemple des classes du programme

client capable d'accéder aux méthodes d'un objet sur le serveur grâce à la méthode
Naming.lookup().
Nous avons utilisé le patron de conception observateur qui permet de faire
communiquer des objets entre eux et d’'éviter le couplage entre les objets. De même
que pour les classes précédentes encapsulant les fonctions de
chiffrement/déchiffrement, la classe SingletonCypher est utilisé.

35
 Télémaintenance

Figure 29 : Le diagramme de classe : envoyer une commande ou une requête SQL.

7. Le module de messagerie instantanée

Pour développer une messagerie instantanée, nous avons préféré utiliser les
sockets au lieu des objets RMI, comme c’était le cas dans la partie précédente, pour
la simple raison de sa simplicité et son utilisation des ressources au mieux.
La messagerie instantanée est constituée par deux modules ou application :
Application serveur : application qui est en attente de connexion ;
Application cliente : application qui se connecte à l’application
serveur.

7.1 Diagramme de classe de l’application serveur

Le serveur se contente d'attendre une demande de connexion, puis se sert du
Socket résultant de cette connexion pour créer un ObjectInputStream et un
ObjectOutputStream.
Comme l’illustre le diagramme de classe de la figure 30, nous avons conçu la
classe TchatServer comportant toute les fonctionnalités du serveur de messagerie et
implémentant la classe lang.Thread pour pouvoir géré et accepté les multiples
connexions en même temps(Multithreading). Le DP observateur est aussi utilisé et
permet de mieux communiquer avec le module gérant l’interface graphique. Les
messages transmis sur le réseau sont chiffrés et déchiffrés une fois reçus par
l’application cliente et vice versant.

36
 Télémaintenance

Figure 30 : Le diagramme de classe : les classes de messagerie coté serveur de messagerie.

7.2 Diagramme de classe de l’application Application cliente

Le client établit une connexion avec le serveur, puis crée un ObjectOutputStream
pour envoyer les messages et ObjectInputStream pour recevoir les messages
provenant du serveur. Comme illustré sur la figure 31, nous avons utilisé la classe
SingletonCypher pour le chiffrement et le DP observateur.

Figure 31 : Le diagramme de classe : les classes de messagerie coté client de messagerie.

37
 Télémaintenance

8. Configuration du serveur LDAP

Nous avons installé et configuré le serveur Apache DS pour répondre à la
demande de connexion sur le réseau local.

8.1. Installation d’ApacheDS

ApacheDS est un projet java, son installation nécessite l’installation de la machine
virtuelle java. Après avoir installé la JRE 1.5 (Java Runtime Environment),
l’environnement qui installe la machine virtuelle, nous avons installé le serveur
LDAP ApacheDS comme le montre la figure 32.

Figure 32: installation d’apacheDS.

Pour pouvoir accéder au serveur ApacheDS, nous avons aussi installé un client
ApacheDS, Apache Directory Studio qui est, comme ApacheDS, un projet
opensource implémenté en Java. Pour plus de détails voir chapitre 2.

8.2. Création d’une partition

Toutes les entrées d’ApacheDS sont stockées dans des partitions et chaque
partition contient une arborescence complète d’entrées, aussi appelé DIT. Nous
avons d’abord créé une partition nommé « MicAssistance ». Pour cela, il faut éditer
le fichier server.xml qui se trouve dans le répertoire de configuration d’ApacheDS
comme décrit ci-dessous :

38
 Télémaintenance

Nous avons ensuite, défini notre arborescence et édité un fichier LDIF des
utilisateurs de la plateforme dont nous avons importé à l’aide d’Apache Studio.
Nous n’avons ensuite qu’à lancer le serveur ApacheDS.

8.3. Exemple de configuration du fichier LDIF

La figure 33 illustre le fichier LDIF de l’arborescence que nous avons utilisé.
Chaque entrée est un dn( Distinguish name). Le dn est le nom complet de l’élément
qui permet de l’identifier de manière unique dans l’arborescence. Nous avons
procédé par la création de la racine d’arborescence MicAssistance et du domaine
ma(Maroc). Toutes les entrées dans la suite hériteront d’eux.
Nous avons par après, créé miccclient et micconsulting, deux autres domaines, l’un
pour les clients MIC et l’autre pour les utilisateurs de MIC.
Nous avons ensuite créé deux groupes nommés respectivement users et groupes
appartenant au domaine micconsulting et enfin, nous avons créé un utilisateur elias
appartenant au groupe users de micconsulting. La suite du fichier a été créée
suivant la même logique. Voici les mots clés utilisés :
dc : Domaine components.
ou : Organisation Unit.
cn : Common name(nom de la personne).
sn : surname.

Figure 33 : Exemple d’un fichier ldif.

39
 Télémaintenance

Chapitre 4 : Implémentation

Dans ce chapitre, nous allons présenter la phase d’implémentation,

l’environnement de développement éclipse que nous avons utilisé,
ainsi qu’une aperçu de la plateforme. Notons que les données
échangées sont crypté au niveau de l’application ; ceci augmentera
d’une manière considérable la sureté de fonctionnement de la
plateforme.

40
 Télémaintenance

1. Introduction

Programmer, c’est gérer à la fois la complexité du problème que l’on veut

résoudre superposé à la complexité de la machine sur laquelle il va être résolu, dans
notre cas nous devons nous confronter aussi à l’architecture réseau complexe passant
par les réseaux locaux à l’inter réseau mondial internet. Nous avons procédé ci-haut
par l’analyse et la conception de notre problématique mais il est plus qu’essentiel de
choisir un langage de programmation qui facilitera à la fois la gestion de la
complexité et la maintenance de l’application. Nous avons choisi pour cela le langage
JAVA qui est un langage orienté objet où tout est objet.
Pour mettre en œuvre une plateforme de contrôle à distance, nous avons élaboré,
pour l’échange des messages, un programme à la base des sockets ; nous avons
aussi utilisé RMI pour la prise en main des serveurs distants et enfin JMF pour la
communication multimédia, nous avons aussi grandement utilisé les design patterns
notamment le singleton et DP observateur. La sécurité était au cœur de notre
préoccupation, pour cela, nous avons utilisé une librairie de chiffrement et de
déchiffrement implémenté au sein de MIC Consulting Group ainsi que LDAP, qui
nous permet d’authentifier tous utilisateurs de la plateforme.

3. Environnement de développement
Durant toute la phase de développement, nous
avons utilisé l’environnement eclipse; qui est
un environnement de développement intégré libre,
extensible, universel et polyvalent, permettant de
créer des projets de développement mettant en
œuvre n'importe quel langage de programmation. Eclipse IDE est principalement
écrit en Java. C’est d’ailleurs pour cette raison et pour sa simplicité d’utilisation que
nous l’avons choisi.
La figure 34 est l’environnement de développent eclipse dont nous avons
utilisé le long durant toute la phase d’implémentation.

41
 Télémaintenance

Figure 34 : Exemple d’environnement de développement.

2. Scenario d’exploitation et vérification architecturale

Dans cette partie, nous allons présenter certains cas d’exploitation, nous
vérifierons ensuite que l’aspect sécurité est bien pris en compte en analysant les
paquets échangés entre le client et le serveur. L’utilitaire wireshark sera utilisé pour
capturer et analyser ces trames.
Wireshark est un logiciel libre d'analyse de protocole, utilisé dans le dépannage,
l'analyse de réseaux informatiques et le développement de protocoles. Ici nous allons
l’utiliser pour pouvoir capturer les informations qui passer sur le réseau lors du
contrôle à distance ; Notons que nous allons utiliser un réseau simple composé
seulement de deux machines et deux applications que nous appellerons dans la
suite :
1. Système MIC : application qui contrôle utilisé par un utilisateur de MIC
Consulting, la figure suivante est son interface graphique :

Figure 35 : Système MIC.

42
 Télémaintenance

2. Système client : application située sur le serveur distant dont l’on veut
accéder, la figure qui suit est son interface graphique :

Figure 36 : système client.

2.1. Scénario 1

Un utilisateur MIC se connecte et autorise à ses clients l’authentification sur le

serveur LDAP ;

Figure 37: Plateforme de contrôle à distance(MIC).

L’utilisateur se connecte à l’application avec son login et son mot de passe.

Figure 38 : Connexion de l’utilisateur.

43
 Télémaintenance

Un utilisateur ayant les droits peut lancer les services appropriés comme
l’autorisation d’accéder au serveur LDAP pour que les clients puissent s’authentifier
à partir des machines distantes.

La figure 39 représente la capture des paquets lors de l’authentification du client

sur le serveur LDAP à travers l’application d’authentification.

Figure 39 : capture authentification

Figure 40 : Autoriser la connexion LDAP.

L’utilisateur MIC lance le serveur de messagerie,

Le serveur de messagerie est situé à MIC consulting Group, le client ayant besoin
d’assistance envoie un message comme le montre la figure suivante.

44
 Télémaintenance

Figure 41:Demande d’assistance.

La figure ci-dessous montre l’échange de message entre le client(Client de MIC)

et un le serveur(utilisateur de MIC).

Figure 42 : communication 1.

Figure 43 : communication 2/ Assistance accepté.

45
 Télémaintenance

Utilisateur MIC accède au serveur, et pourra lancer les commandes sur le serveur.

Figure 44: Lancer une commande sur le serveur distant.

La figure 45 représente la capture des paquets lors de l’envoie de la commande

ipconfig à partir de la machine 192.168.1.3 vers 192.168.1.2.

Figure 45: capture de la commande ipconfig.

La figure 46 représente la capture des paquets lors de l’envoie des résultats de la

commande ipconfig ci-haut citée.

46
 Télémaintenance

Figure 46: résultant de la commande ipconfig

Utilisateur MIC peut lui envoyer un fichier.

Figure 47 : envoie d’un fichier.

La figure 48 représente la capture des paquets lors de l’envoie d’un fichier.

47
 Télémaintenance

Figure 48: Capture Envoie du fichier

Figure 49 : Envoie du fichier réussi.

2.2 Scénario 2

Les figures illustrent deux personnes (un client et un utilisateur MIC) en

communication audio-visuelle.

Figure 50 : communication audio-visuelle.

48
 Télémaintenance

La figure 51 représente la capture des paquets lors d’une communication audio-

visuelle.

Figure 51:capture des paquets audio-visuels

2.3. Vérification de niveau de sécurité avec wireshark

Les deux applications établissent une connexion TCP et l’application distante

cherche l’objet RMI dans le registre RMI sur le port 1099 (voir Figure 52 ci-dessous).

Figure 52 : Etablissement de connexion RMI.

La figure 53 suivant montre que RMI se situe juste au dessous de la couche

transport du modèle OSI et internet. Il ajoute alors une autre couche qui prend en
compte les objets Java se situant sur une autre machine virtuelle.

49
 Télémaintenance

Figure 53 : RMI se situe au dessus de la couche Transport.

Toutes les données échangées à travers le réseau sont chiffrées (voire Figure 55
suivante).

Figure 54 : Les données, chiffrement.

50
 Télémaintenance

Chapitre 5: MICTopus

Dans ce chapitre, nous allons présenter l’application MICTopus,

l’application distribuée permettant de faire l’agrégation d’une base de
données vers une autre base de données ayant le même schéma.

51
 Télémaintenance

1. Introduction

MicTopus est une application qui doit assurer l’agrégation des données d’une base
de données vers une autre ayant le même schéma.
Le problème revient à gérer l’ordre d’agrégation des tables selon la présence des
clés étrangères puis de commencer l’agrégation tout en gardant la trace des nouvelles
valeurs des clés primaires et enfin en les remplaçant dans les champs de clés
étrangères.
Notons que l’agrégation est une relation entre deux classes spécifiant que des
objets d'une classe (la classe cible) sont les composants de l'autre classe (la classe
source).
Pour résoudre ce problème, nous avons proposé deux algorithmes :

2. Premier Algorithmique

Notons qu’il est important de garder l’historique d’agrégation pour pouvoir gérer
des clés étrangères et les futures agrégations.
Soient : Gtopus: table de correspondance des clés primaires.
Ttopus : Table comportant les noms de tous les autres tables de la base
de données.
Gtable : la table qui va être agrégée.
BdDD : Base de données de destination.
BdDS : Base de données source

L’organigramme suivant représente l’algorithme proposé.

52
 Télémaintenance

Construire la table Ttopus constitué par le schéma de la BdDS (non

transféré)

Trier Ttopus par ordre croissant suivant le nombre des clés. (On commence
par celle qui n’a que de clé primaire)

Pour chaque table de Ttopus

Si la table n’a
qu’une clé primaire
oui non

Construire la table Gtopus suivant le dernier

enregistrement de Gtopus correspondant à Pour chaque clé étrangère
la table

Remplacer les clés correspondant dans la Chercher la clé

table Gtable correspondant dans Gtopus

Insérer la table Gtable dans la base BdDD

Mettre en jour Ttopus Si la clé existe

dans Gtopus
enregistrement de Gtopus correspondant à la
table. oui
enregistrement de Gtopus correspondant à la
table. non
enregistrement de Gtopus correspondant à la
table.
Remplacer la clé correspondant dans Gtable

Attendre (Mettre la table à la

Insérer la table Gtable dans la base BdDD queue de Ttopus)
Am

Mettre en jour Ttopus

Figure 55 : Algorithme brut proposé.

Amélioration : Puisque les clés sont numérique et ordonnées, au lieu

d’enregistrer toutes les clés correspondant à une table ayant des clés primaires. On

53
 Télémaintenance

enregistre la clé du premier enregistrement de la table et celle du dernier

enregistrement. Ceci augmentera les performances du système en termes de temps et
de gestion de la mémoire. Lors de l’implémentation de la solution, c’est l’algorithme
suivant qui sera utilisé.

3. Deuxième Algorithmique
//algorithme côté BdDS
Début
Construire le schéma de BdDS(Ttopus)
Trier Ttopus suivant COLUMN_KEY primaire
Pour i=1 jusqu’à n=card(Ttopus) faire
Début
Type_clef= Type_clef_de_Ttopus[i] //unique primaire ou pas
Sélectionner toutes les données de la table Ttopus[i] dans BdDS
Transférer ses données pour être insérer dans BdDD
Si Transferer(Ttopus[i])== echec _insertion_Table_Entrant
Mettre Ttopus[i]) à la queue pour être renvoyer.
Fin.
Fin.
//algorithme côté BdDD
Début
Table_Entrant=Enregistrement_Entrant
Si Type_clef== « primaire_type » faire
Début
Ind=dernier Gtopus .Ind_end // dernier Gtopus de Table_Entrant
Table_Entrant.COLUMN_KEY=Ind+ Table_Entrant.COLUMN_KEY
Inserer Table_Entrant dans BdDD
Fin
Sinon
Début
Ind=dernier ( Gtopus .Ind_end)+ Table_Entrant.COLUMN_KEY
// dernier Gtopus de Table_Entrant
Table_Entrant.COLUMN_KEY_primaire=Ind
Pour i=1 jusqu’à n= card(Type_clef_etrangeres) faire
Début
Si Table_Entrant_clef[i]<=Gtopus. Ind_fin_source faire
Ind_Et[i]=Table_Entrant(Ind_begin)+ Table_Entrant.COLUMN_KEY
Sinon
//la clé étrangère n’a pas sa correspondante primaire
Retourner (echec _insertion_Table_Entrant).
Fin
Inserer Table_Entrant dans BdDD
Fin
Fin.

C’est ce dernier algorithme que nous sommes entrain d’implémenté.

54
 Télémaintenance

CONCLUSION ET PERSPECTIVE
Nous avons élaboré durant ce stage, la plateforme de contrôle à distance à travers
Internet. Internet étant un réseau non fiable, nous avons intégré une librairie de
chiffrement pour tout le trafic jugé critique, nous avons enfin intégré dans la
plateforme la messagerie instantanée et le module audio-visuel qui permettront
respectivement aux utilisateurs d’échanges les messages instantanés et de tenir des
vidéoconférences. Par ce projet, j’ai aussi découvert la méthode Scrum pour la
gestion des projets, le développement d’une application réseau, l’encapsulation des
algorithmes de chiffrement ainsi que les indices de qualité algorithmiques et enfin,
j’ai assisté sur d’autres projets qui étaient en cours au sein de MIC Consulting Group,
ce qui a apporté beaucoup à mon parcours personnel et professionnel. Par là,
j’apprécie vivement cette occasion qui m’a été donnée.
Aussi complexe qu’il soit, tout projet nait d’une idée, cette idée qui, murit pour
donner une nouvelle approche et innovation doit être entretenu et revue pour
répondre astucieusement et minutieusement aux besoins des utilisateurs, tel est le
cas pour notre projet. Nous préconisons sa complexité, et nous demandons un suivi
pour maintenir son niveau de sécurité et pour accroitre sa sureté de fonctionnement.
Par ailleurs nous recommandons d’intégrer les services VOIP (Voice over IP) et de
signalisation des messageries instantanées, ceci permettra d’être à tout moment à
l’écoute des clients pour leur apporte l’assistance.
MicTopus nous a apporté une compréhension élargie sur plusieurs
problématiques que courent les bases des données, notamment, son niveau d’accès
qui peut, surchargé ou trop demandé, être compromis, d’où l’intérêt de répartir les
données sur plusieurs serveurs tout en assurant la synchronisation des données. Ceci
nécessitera aussi une politique d’accès aux ressources réseaux et systèmes. Cette
politique pourrait être gérée au niveau applicatif de la plateforme, ce qui permettra
une distribution optimale du trafic et l’amélioration de l’utilisation global du réseau.

55
 Télémaintenance

Bibliographie
1. Penser en java seconde édition, Bruce Eckel.
2. JAVATM MEDIA FRAMEWORK,www.sun.com/jmf.
3. Understanding LDAP Design and Implementation(IBM), ibm.com/redbooks.
4. Java Network Programming de Elliotte Rusty Harold (O.Reilly, 1997).
5. Support de cours VOIP Réseaux et Système de l’ENSA de Marrakech 2009,
Pr.Idboufker Noureddine.
6. Support de cours UML Master Réseaux et Système de l’ENSA de Marrakech 2010,
Eng. JAKJOUD Abdeslam.
7. UML par la pratique, Etudes de cas et exercices corrigés 5ème édition ,EYROLLES,
Pascal Roques.
8. Network-programming with RMI Assignment for the M.Sc. Course on Distributed
Systems Adrian Reber.
9. Support de Cours JAVA RMI 2010, 5ème Génie informatique , ENSA de Marrakech.
10. Scrum et XP depuis les Tranchées, Comment nous appliquons Scrum, Henrik
Kniberg.
11. http://www.siteduzero.com/tutoriel-3-65547-soyez-a-l-ecoute-de-vos-objets-le-
pattern-observer.html , simple IT par Pierre Dubuc et Mathieu Nebra.
12. Communication synchrone entre programmes par RPC et RMI, par Pr. Michel
RIVEILL, Pr.Roland BALTER, MC.Fabienne BOYER.
13. Design Patterns CD,Elements of reusable Object-Oriented Software 1998, Erich
Gamma,Richard Helm,Ralph Johnson, John Vlisides.
14. www. dev.mysql.com, by Stefan Hinz, Team Lead, Paul DuBois,Jonathan
Stephens,Martin 'MC' Brown,Anthony Bedford .
15. Distributed Programming with Java, Training Course, Gabriel Oteniya et Chau
Keng Fong.
16. support de cours Administration Réseau Annuaire LDAP , Abdou Guermouche.

56
 Télémaintenance

Glossaire
Directeur de produit (Product Owner) : Personne responsable de produire et
maintenir à jour le backlog de produit. C'est lui qui en détermine les priorités et qui
prend les décisions concernant l'orientation du projet.

ScrumMaster : Membre de l'équipe dont l'objectif principal est de la protéger des

perturbations extérieures.Il est complètement transparent pour la communication
entre l'équipe et les clients et n'a aucun pouvoir hiérarchique sur l'équipe. C'est en
revanche un facilitateur pour les problèmes non techniques de l'équipe.

Backlog de produit (Product Backlog) : Liste des fonctionnalités qui devront être
réalisées par le logiciel.

Backlog de sprint (Sprint Backlog): Liste des tâches à accomplir pendant un sprint.
Elles correspondent à la réalisation des items de backlog du produit affectés au
sprint.

Mêlée quotidienne (Daily Scrum) : Réunion quotidienne de 15 minutes qui a pour

but de faire le point sur ce qui a été fait depuis la dernière mêlée, ce qui est prévu de
faire jusqu'à la prochaine et quelles sont les embûches rencontrées durant le travail.

Sprint : Nom d'une itération dans Scrum. Cette itération dure 30 jours calendaires en
théorie, mais en pratique on utilise plutôt entre 2 et 4 semaines. Pendant une
itération, l'équipe doit développer une liste d'items du backlog de produit qui a été
définie au début de ce sprint.

Graphique d'avancement (Burndown Chart) : Graphique qui montre la tendance du

reste à faire total de jour en jour (pour les sprints) ou de sprint en sprint (pour les
releases).

BdDD/BdDS : Base de données de Destination/base de données sources.

57