Ecole Nationale des Sciences de l’Informatique GL Trade

Introduction

Ces dernières années, les entreprises transnationales n’ont cessé de réaliser une montée
en puissance et en nombre. Pour les transnationales se spécialisant dans le développement et
la production de logiciels informatique, la synchronisation entre les différentes équipes des
différentes filiales devient une tâche primordiale pour le bon avancement du travail.

C’est dans ce contexte que se situe ce travail qui consiste à la réalisation d’une
application qui assure la synchronisation entredeux environnements distants, dans ce cas les
deux environnements de deux filiales distantes, pour le compte de l’entreprise transnationale
GLTRADE.

Ce rapport se compose de quatre chapitres. Le premier chapitre est consacré à la

présentation de l’organisme d’accueil. Le deuxième chapitre est relatif à l’analyse et à la
spécification des besoins, il contient une explication détaillée des exigences auxquelles l’outil
doit répondre. Le chapitre suivant développe la conception de l’application et le dernier
chapitre, réalisation, décrit l’environnement de développement et les différentes techniques
utilisées lors du développement de l’application.

Stage d’Eté 1
 Ecole Nationale des Sciences de l’Informatique GL Trade

Chapitre 1 : Présentation générale

I- Introduction

Dans le cadre de notre formation d’ingénieurs informaticiens à l’Ecole Nationale des

Sciences de l’Informatique, nous avons eu l’occasion d’effectuer notre projet d’été au sein de
la société GL Trade. Le projet consiste en la synchronisation d’environnements de
développement distants.

Dans ce chapitre, nous présentons le cadre général de notre projet. En effet, nous
commençons par la présentation de l’organisme d’accueil GL Trade. Ensuite, nous décrivons
le sujet du projet.
II- Présentation de l’organisme d’accueil

1. GL Trade

Le groupe GL Trade a été créé en 1987 par Pierre GATIGNOL et Louis Christophe
LAURENT. Il offre à la communauté financière une large gamme de solutions logicielles
pour couvrir le processus complet d’un ordre de bourse, du donneur d’ordre au trader :
logiciels de négociations et de gestion des ordres, réseau, informations de marchés, logiciels
de gestion de risques et services associés du Front au Back Office. Tous ces services sont
accessibles à travers son réseau propriétaire GLNET connecté à plus de 500 institutions en la
matière et plus de 80 marchés à travers le monde.

GL Trade est une société anonyme dont le capital social dépasse les 300 millions
d’Euros.

C’est un groupe international de 1100 collaborateurs, répartis sur 26 filiales dans 23

pays comme l’indique la figure 1. Elle est au service de plus de 3500 clients à qui elle
s’engage à fournir des solutions de capture d’ordres basées sur des technologies ouvertes et
100% compatibles avec des applications tierces, des logiciels intégrés en temps réel pour la
meilleure exécution possible et des modules de gestion des ordres compétitifs pour le respect

Stage d’Eté 2
 Ecole Nationale des Sciences de l’Informatique GL Trade

des marges. Le Groupe GL Trade s’est développé au fil des années et aujourd’hui il est
devenu l’un des acteurs incontournables sur son marché.

Figure 1: Implantations géographiques de GL Trade dans le monde

2. GL Trade MENA

GL Trade Tunis est l’un des trois centres de développement de la société à travers le
monde. C’était au début une filiale de l’Ubitrade. Dirigée par Yassine BRAHIM (the chief
executive officer d’Ubitrade ), GL Trade Tunis ou GL Trade MENA (Middle East and North
Africa) fournit les supports techniques de développement aux clients de la région. GL Trade
MENA engage 136 personnes dont 85% sont des ingénieurs de recherche et développement.
Le centre de Tunis couvre toute la région de l’Afrique du Nord et du Moyen Orient et en
particulier Dubaï où GL Trade a signé un accord de partenariat avec une bourse de la place.

Stage d’Eté 3
 Ecole Nationale des Sciences de l’Informatique GL Trade

III- Présentation du sujet

L’objectif de notre sujet au sein de GL Trade est la synchronisation d’environnements

de développements distants. En d’autres termes, c’est la synchronisation des versions (code
source) entre deux environnements de travail partagés : un premier à Tunis et un deuxième à
Londres.
IV- Conclusion

Ce chapitre nous a servi à mettre le projet dans son cadre. En effet, ce projet d’été est
effectué dans GL Trade et consiste à la synchronisation d’environnements de développement
distants. Le chapitre suivant permettra d’introduire plusieurs concepts nécessaires à la
compréhension de ce chapitre à savoir : le Shell Unix, les fichiers cron et crontab, etc.

Stage d’Eté 4
 Ecole Nationale des Sciences de l’Informatique GL Trade

Chapitre 2 : Analyse et spécification

des besoins

Dans ce chapitre, nous allons énumérer les différents besoins fonctionnels et non
fonctionnels de notre application, lesquels besoins vont éclaircir mieux son fonctionnement.
I- Etude de l’existant et solution retenue

1. Etude de l’existant

GL Trade Tunis est l’un des trois centres de développement de la société à travers le
monde. Vu l’importance de son rôle dans le cursus de développement, les codes sources se
trouvant sur le serveur GL Trade MENA doivent toujours être mis à jour par rapport au
serveur central se trouvant à Londres. Ce contrôle se base sur les dates de modification de ces
codes (versions). C'est-à-dire, chaque version du serveur de Londres plus récente que celle se
trouvant sur le serveur de Tunis doit être téléchargée pour remplacer l’ancienne version.

Le répertoire de travail concerné par ces modifications est le répertoire dev32. Il

contient toutes les versions en cours de création ou de modification. Ces versions sont
regroupées par type dans des sous-répertoires, donc on trouve un répertoire « java » qui
contient les codes java, un répertoire « inc » qui contient les .h et .ph, etc. Donc la
synchronisation se limitera seulement à ce répertoire seulement au niveau des deux serveurs.
Le répertoire dev32 existe sur les deux serveurs et donc la même arborescence aussi et les
mêmes sous-répertoires.

2. Solutions envisagées

Une première alternative est de se connecter manuellement au serveur distant (Londres),

lister les codes sources existants et dégager les fichiers récents, les télécharger pour enfin
remplacer les anciens codes. Dans le cas où une version existe sur le serveur distant et ne
figure pas sur le serveur local, là aussi elle doit être téléchargée. Il faut mentionner qu’il existe
un système de gestion de contenu (Content Management System ou CMS) qui permet de
récupérer une ancienne version s’il y avait une erreur dans la nouvelle et donc le responsable
sur cette opération n’a pas à se soucier du fonctionnement de cette version. Bien que cette

Stage d’Eté 5
 Ecole Nationale des Sciences de l’Informatique GL Trade

tâche peut sembler simple, un administrateur aura une grande difficulté à localiser toutes les
nouvelles versions en les comparant avec les versions existantes, sans qu’une ou plusieurs
versions ne passent inaperçues ou sans se tromper sur l’une d’elles, sans oublier la perte de
temps qui accompagne cette tâche.

Une autre alternative sera d’automatiser ce traitement, à savoir la connexion au serveur

distant, la comparaison des fichiers, le transfert de fichiers, etc. Ainsi, l’administrateur aura
seulement la tâche de configurer l’application effectuant ce traitement en lui passant par
exemple l’adresse du serveur distant, le mot de passe, le moment de l’exécution, etc. De cette
manière, la synchronisation entre les deux environnements de développement (serveurs
distants) devient facile, sans risque d’erreurs et beaucoup plus rapide par rapport à la
procédure habituelle.
3. Solution retenue

Donc le travail demandé sera de développer une application qui automatise la

synchronisation entre deux environnements de développement distants (Tunis/Londres) pour
pallier aux problèmes de la synchronisation manuelle.
V- Besoins fonctionnels

Cette application doit donc fournir plusieurs fonctionnalités telles que :

✔ synchroniser les codes sources : un code source doit être téléchargé dans deux
cas possible : si sa date de modification dans le serveur principal (Londres) est
plus récente que sa date de modification sur le serveur local (Tunis) ou s’il existe
sur le serveur distant et il n’a pas de version antérieure sur le serveur local,
✔ respecter l’arborescence des codes sources : tout fichier téléchargé à partir du
serveur distant doit garder le même emplacement sur le serveur local (la même
arborescence sur les deux serveurs),
✔ garder la trace des opérations effectuées dans un fichier journal,
✔ assurer le lancement automatique de la synchronisation a un moment précis.
VI- Besoins non fonctionnels

Pour le bon fonctionnement de cette application, plusieurs contraintes doivent être

respectées. Parmi ces contraintes, on trouve :
✔ l’optimisation du temps d’exécution qui peut être long vu l’importance du
nombre de versions existantes,
✔ la réutilisabilité de l’application pour d’éventuelle amélioration.
VII- Conclusion

Stage d’Eté 6
 Ecole Nationale des Sciences de l’Informatique GL Trade

Une fois la solution à développer est fixée et les besoins fonctionnels et non fonctionnels
énumérés, il est possible maintenant de concevoir clairement l’architecture de notre système ce qui
sera le sujet du chapitre suivant.

Stage d’Eté 7
 Ecole Nationale des Sciences de l’Informatique GL Trade

Chapitre 3 : Conception du logiciel

Ce chapitre comporte une première section relative à la conception générale de cette

application et qui décrit le comportement global de l’application. La deuxième section décrit
sa conception détaillée et les solutions choisies concernant la connexion et le transfert de
fichiers.
I- Conception générale

Notre conception doit prévoir toutes les communications et les échanges entre les deux
serveurs. Pour y parvenir, il faut mettre en place un scénario de synchronisation possible.
Cette application reçoit en entrée un fichier main_directories.txt à partir duquel, on peut lire
les emplacements des répertoires concernés par la synchronisation. Premièrement, le serveur
local se connecte au serveur distant. Sur ce dernier, il y a génération d’un fichier
all_files_list_dist qui contient la liste des fichiers se trouvant dans les répertoires mentionnés
dans le fichier main_directories.txt sur le serveur distant. Ce fichier sera téléchargé par la
suite à partir du serveur distant. De nouveau sur le serveur local, il y a génération d’un fichier
all_files_list_locqui contient la liste des fichiers se trouvant dans les mêmes emplacements
mais sur le serveur local. Une fois les deux fichiers générés, leur comparaison devient
possible et il y aura comme résultat un fichier maj_output qui contient la liste des fichiers à
télécharger du serveur distant. A partir de cette liste, le téléchargement des mises à jour est
effectué et le travail est terminé.

Un premier point à remarquer est que pour envoyer et recevoir des fichiers et ensuite
faire des traitements là-dessus, il faudrait soit avoir une reproduction exacte du répertoire de
travail, soit avoir une connaissance parfaite des chemins des fichiers et des répertoires. Pour
pallier à ce problème, nous allons utiliser les variables d’environnements qui doivent exister
sur les deux serveurs sans se soucier de leurs contenus.

Stage d’Eté 8
 Ecole Nationale des Sciences de l’Informatique GL Trade

Les variables d’environnements utilisées jusqu’ici sont :

➢ RIMS_DIR : Cette variable contient le chemin du répertoire principal de travail. A la
suite nous allons trouver la liste des répertoires à considérer et contenus dans ce
dernier.
➢ RIMS_COM : Elle contient le chemin du répertoire « com » contenant les fichiers
.com,
➢ RIMS_INC : Elle contient le chemin du répertoire « inc » contenant les fichiers .h et
.ph,
➢ RIMS_PC : Contient le chemin du répertoire « pc » contenant les fichiers pc_sub,
➢ RIMS_PC3 : Contient le chemin du répertoire « pc3 » contenant les fichiers
pc_main,
➢ RIMS_JAVA : Contient le chemin du répertoire « java » contenant les fichiers .java,
➢ RIMS_SQL : Contient le chemin du répertoire « sql » contenant les fichiers .sql,
➢ RIMS_DATA : Contient le chemin du répertoire « data » contenant les fichiers data.
Nous trouvons encore d’autres variables d’environnements telles que :
➢ DIR_UPDATE : C’est le chemin du fichier qui contient la liste des répertoires
(variables d’environnements) à prendre en considération pour effectuer les mises à
jour,
➢ LOG_FILE : C’est le chemin du fichier journal qui gardera la trace du
fonctionnement du programme,
➢ ALL_FILES_OUTPUT : C’est le chemin du fichier que le programme génèrera et
qui contient la liste des fichiers présents dans notre répertoire de travail (RIMS_DIR).
On aura deux exemplaires de ce fichiers : l’un issu du serveur local et l’autre issu du
serveur distant.
➢ MAJ_OUTPUT_FILE : C’est le chemin du fichier qui contiendra les mises à jour à
télécharger.
➢ USER_DIST : C’est le compte utilisateur avec lequel on se connecte sur le serveur
distant.
➢ IP_DIST : C’est l’adresse du serveur distant.
➢ PASS : C’est le mort de passe du compte utilisateur utilisé.

Ainsi en définissant ces variables, les entrées du fichier main_directories.txt ne sont

pas des emplacements de répertoires, mais des variables d’environnement contenant ces
valeurs.
Stage d’Eté 9
 Ecole Nationale des Sciences de l’Informatique GL Trade

Il reste à mentionner que le choix de ces variables d’environnements n’est pas définitif
et on peut selon les besoins leur apporter des modifications, soit en ajoutant de nouvelles
variables, soit en modifiant les valeurs de celles existantes.

Maintenant, revenons au fonctionnement de l’application. D’après la figure 1, on peut

distinguer cinq grandes étapes :
➢ Connexion et génération de la liste des fichiers (all_files_list_dist) sur le serveur
distant. Cette étape est gérée par le module list_dist.
➢ Transfert de all_files_list_dist du serveur distant vers le serveur local. Cette étape est
gérée par le module dist_to_loc.
➢ Génération de la liste des fichiers sur le serveur local (all_files_list_loc). C’est le
module gen_all_file_list qui gère cette étape.
➢ Comparaison de all_files_list_dist et all_files_list_loc et génération de la liste des
mises à jour (maj_output). C’est le module compare_files qui assure cette opération.
➢ Téléchargement des mises à jour si elles existent. Ce traitement est assuré par le
module maj_download.

Autre que ces modules, on trouve d’autres modules supplémentaires qui son très
importants pour le bon fonctionnement de l’application :
➢ Le module var_dist, qui permet de récupérer la valeur d’une variable
d’environnement du serveur distant.
➢ Le module loc_to_dist, qui permet de placer le fichier main_directories.txt
(DIR_UPDATE) sur le serveur distant pour s’en servir lors de la génération de la liste
des fichiers sur le serveur distant.
➢ Le module convert_time qui prend en entrée le fichier all_files_list_dist pour
convertir les dates et heures de modification des fichiers distants aux dates et heures
de modification des fichiers locaux. Ce traitement est nécessaire lorsque les deux
serveurs, local et distant, n’appartiennent pas au même fuseau horaire, ce qui est le cas
pour nous, pour pouvoir ensuite effectuer la comparaison correctement.
➢ Les modules clean et clean_dist qui ont pour rôle d’effacer tout fichier tampon utilisé
au cours de l’exécution de l’application.
VIII- Conception détaillée

Stage d’Eté 10
 Ecole Nationale des Sciences de l’Informatique GL Trade

Une fois tous les modules et les étapes définis, il est temps de se concentrer maintenant
sur chaque module indépendamment.

Au début, ce sont les modules principaux qui seront décrits c'est-à-dire ceux qui
correspondent aux cinq étapes décrites auparavant.

Le premier module à décrire est le module gen_all_files_list. Il est très important vu

que ce traitement sera exécuté sur les deux serveurs pour pouvoir générer pour l’un et l’autre
la liste des fichiers contenus dans le répertoire RIMS_DIR. Ce module lit à partir du fichier
DIR_UPDATE les répertoires à mettre à jour, puis pour chaque répertoire, il invoque un autre
module, gen_files_list, qui génère la liste des fichiers contenus dans l’arborescence du
répertoire lu. A la fin de ce traitement, on obtient le fichier ALL_FILES_OUTPUT. Ceci
implique que les deux modules gen_all_files_list et gen_files_list doivent être présents aussi
bien sur le serveur distant que sur le serveur local, ce qui nous amène au deuxième module
qui est list_dist.

Ce module, list_dist, prend comme paramètre la valeur de la variable d’environnement

RIMS_DIR du serveur distant. C’est le répertoire où se trouvent les deux modules
gen_all_files_list et gen_files_list sur le serveur distant. Le rôle de ce module est de se
connecter au serveur distant et ensuite générer la liste des fichiers distants via
gen_all_files_list.

Une fois la liste distante est générée, le module dist_to_loc se charge de son transfert du
serveur distant vers le serveur local en prenant comme paramètres l’emplacement de ce fichier
sur le serveur distant et l’emplacement où il doit être stocké sur le serveur local.

Jusqu’ici les étapes terminées sont les deux premières. Celle qui vient juste après est la
génération de la liste des fichiers sur le serveur local et c’est le module gen_all_files_list qui
assure cette tâche comme mentionné auparavant.

Maintenant que les deux fichiers, la liste des fichiers sur le serveur local et la liste des
fichiers sur le serveur distant, sont à notre disposition, la comparaison peut être effectuée via
le module compare_files qui prend comme paramètres les deux listes : le premier paramètre
est le fichier local, le deuxième est le fichier distant (l’ordre est très important pour la fiabilité
des résultats). La comparaison entre les fichiers se base sur leurs dates de modification. Le
Stage d’Eté 11
 Ecole Nationale des Sciences de l’Informatique GL Trade

test se fait tout d'abord sur les années, les mois, puis les jours, ensuite les heures et enfin les
minutes pour déterminer si un fichier du serveur distant est plus récent que son homologue sur
le serveur local. Le produit de ce module est le fichier MAJ_OUTPUT_FILE qui contient
les fichiers existants sur le serveur distant et qui sont plus récents que ceux existants sur le
serveur local ou encore les fichiers qui existent sur le serveur distant et non sur le serveur
local.

La dernière étape est donc le téléchargement des mises à jour. C’est le module
maj_download qui assure ce traitement. Ceci consiste à télécharger chaque fichier présent
dans le fichier MAJ_OUTOUT_FILE et le placer dans le répertoire équivalent du serveur
local à celui où il était placé sur le serveur distant, par exemple si un fichier était placé dans le
répertoire RIMS_COM sur le serveur distant, il doit aussi être placé dans le répertoire
RIMS_COM sur le serveur local. Ce module fait appelle à un autre, dist_to_loc, qui assure le
transfert d’un fichier du serveur distant vers le serveur local. Ce module prend comme
paramètres la source du fichier à télécharger et la destination où il doit être stocké.

Ainsi les grandes lignes sont tracées et reste à décrire les autres modules
supplémentaires.

Comme mentionné auparavant, l’entrée de cette application est le fichier

DIR_UPDATE qui contient la liste des répertoires à mettre à jour. Ce fichier doit être
éditable par l’administrateur selon ces besoins et puisque ce fichier doit être présent sur le
serveur distant pour la génération de la liste des fichiers, on doit donc en créer une copie sur le
serveur distant. C’est au module loc_to_dist d’assurer cette opération. Il a deux paramètres :
la source (serveur local) et la destination (serveur distant).

Lors du déroulement de l’application, plusieurs situations nécessitent la connaissance

des valeurs des variables d’environnements du serveur disant. Le module var_dist assure
cette fonction en se connectant au serveur distant et récupérant la valeur de cette variable. Il
prend donc comme paramètre le nom de la variable d’environnement nécessaire pour
renvoyer sa valeur.

Un autre module important pour le bon déroulement de notre application est

convert_time. Ce module est nécessaire vu que les deux serveurs n’appartiennent pas au
même fuseau horaire : l’un à Tunis, l’autre à Londres. Deux paramètres sont passés à ce
Stage d’Eté 12
 Ecole Nationale des Sciences de l’Informatique GL Trade

module : le fichier à convertir (celui téléchargé du serveur distant) et le fichier avec les dates
convertit dans l’heure du serveur local.

Enfin, les deux modules clean et clean_dist sont responsable d’enlever tous les fichiers
qui ont servi lors de la synchronisation : clean pour le nettoyage au niveau du serveur local,
clean_dist au niveau du serveur distant.

Bien qu’une description détaillée de tous les modules soit fournie, il reste encore à fixer
quelques choix concernant le protocole de connexion, la méthode d’authentification et le
protocole de transfert de fichiers qui sont primordiaux pour le développement de l’application.

Concernant le protocole de connexion, il y a deux solutions possibles : soit utiliser le

protocole Telnet, soit utiliser SSH (Secure SHell). Cependant, nous avons penché pour la
connexion via SSH pour des raisons de sécurité. L'échange de clé de chiffrement en début de
connexion permet d'échanger des trames chiffrées durant la connexion, empêchant ainsi
l'utilisation d'un sniffer permettant de voir en clair ce que fait l'utilisateur. L'utilisation de SSH
permet ainsi d'éviter la compromission des mots de passe, qui circulent en «clair» sur le
réseau. En outre, cela oblige à disposer d'une authentification renforcée des machines, pas
seulement basée sur le nom ou l'adresse IP (qui peuvent être falsifiés) [Net1].

Pour SSH, il existe deux méthodes d’authentification : authentification par mot de passe
ou authentification par clés symétriques.

Pour la première méthode, lors de la connexion, l’utilisateur est invité à entrer un mot
de passe qui est transmis au serveur, qui le compare à une empreinte du mot de passe associé
à l'utilisateur. Le mot de passe en clair est encapsulé dans une communication secrète, et
devient «inviolable» sur le réseau.

Pour l’authentification par clés symétriques, il y a trois étapes principales pour établir
une connexion et qui sont [Net1]:
➢ Génération de «bi-clé asymétrique» (c'est à dire un couple clé-privée/clé-publique)
sur une machine, en général la machine cliente. Cette bi-clé est stockée dans un sous-
répertoire (par exemple ~/.ssh avec OpenSSH) de l'utilisateur.
➢ Copie de la clé publique sur la machine serveur sur laquelle on souhaite pouvoir
utiliser cette authentification. Cela consiste à ajouter la ligne correspondant à la clé
Stage d’Eté 13
 Ecole Nationale des Sciences de l’Informatique GL Trade

publique présente dans le répertoire où elle a été générée (par exemple, le contenu du
fichier ~/.ssh/id_dsa.pub) dans un fichier du serveur situé dans le répertoire de
l'utilisateur (par exemple ~/.ssh avec OpenSSH). Le nom de ce fichier dépend de la
version de SSH mais se nomme souvent authorized_keys ou authorization.
➢ Entrée de la «passphrase» au moment de la séquence de connexion. Afin
d'automatiser l'entrée de la «passphrase», il est possible d'utiliser un utilitaire
permettant de ne la rentrer qu'une seule fois par session locale : ssh-agent.

En utilisant cette méthode d’authentification, il suffit d’effectuer les trois étapes

précédentes une seule fois pour permettre à cet utilisateur de toujours se connecter au serveur,
sauf que ceci implique d’effectuer des changements dans l’un des fichiers du serveur distant.
C’est pourquoi cette solution a été rejetée suite aux exigences de l’entreprise et nous avons
opté donc pour l’authentification par mot de passe.

En ce qui concerne le transfert de fichiers, il existe trois protocoles de transfert de

fichiers : FTP, SFTP ou SCP.

FTP ou File Transfer Protocol a été utilisé pendant de nombreuses années en tant que
principale méthode pour transférer des fichiers d'un ordinateur à un autre. Les clients FTP et
les serveurs sont très largement disponibles. Toutefois, il existe des problèmes de sécurité
avec FTP. Quand vous établissez une connexion FTP, votre mot de passe sur le système
distant est transmis sans aucune forme de cryptage. FTP n’est donc généralement pas
recommandé.

L’alternative sécurisée de FTP est SFTP (un peu comme FTP, avec un peu moins de
fonctionnalités mais encore plus sécurisé) et SCP (Secure Copy), sauf que ces deux protocoles
offrent différents avantages.

Suite à l’établissement d’une connexion via SFTP, l’utilisateur peut effectuer une série
d’opération (y compris plusieurs qui ne sont pas réellement des transferts, tels que lister le
contenu d’un répertoire ou même la suppression de fichiers sur le système distant). Avec SCP,
une seule commande permet de transférer un fichier ou un groupe de fichiers, mais pour lister
par exemple les fichiers d’un répertoire sur le système distant, il faudrait y procéder en
utilisant une session SSH indépendante [Net2].

Stage d’Eté 14
 Ecole Nationale des Sciences de l’Informatique GL Trade

Or, selon les étapes décrites auparavant, le transfert de fichiers est indépendant de tout
autre traitement, et toute opération autre que le transfert de fichiers sur le serveur distant est
assurée par SSH, ce qui nous mène à choisir SCP qui a l’avantage de transférer un groupe de
fichier ce qui n’est pas le cas avec SFTP.
IX- Conclusion

Dans ce chapitre nous avons détaillé la conception de notre application et des différents
modules qui la forment. Et maintenant, après avoir détaillé la conception, fixé le protocole et
la méthode de connexion ainsi que le protocole de transfert, nous allons passer au chapitre
suivant qui traite la phase de réalisation.

Stage d’Eté 15
 Ecole Nationale des Sciences de l’Informatique GL Trade

Chapitre4: Réalisation

Dans ce chapitre, nous présentons le travail réalisé, le choix de la plateforme utilisé ainsi que
l’environnement de développement et les différentes techniques utilisées pour le codage de la
solution.
I- L’environnement de développement

1. Environnement matériel :

La mise en place de mon application est faite sur une machine qui a les caractéristiques
suivantes :
➢ Processeur Intel Pentium 4 avec une fréquence d’horloge de 3.06GHz.
➢ Mémoire vive de taille 1 Go.
➢ Disque dur de capacité 80Go.
➢ Ecran 17 pouces.
2. Environnement logiciel

2.1.Red Hat Entreprise Linux

Le système d’exploitation utilisé pour le développement de l’application est Red Hat

Enterprise Linux (souvent abrégé RHEL). C’est une distribution Linux produite par Red Hat et
orientée vers le marché commercial et les serveurs d'entreprise. Red Hat prend en charge chaque
version du logiciel pour une durée de 7 ans après sa sortie. Tout l'appui officiel, toutes les
formations et certifications de Red Hat — RHCT, RHCE, RHCSS et RHCA — pour le déploiement
de matériel et de logiciel portent sur la plateforme Red Hat Enterprise Linux.

De nouvelles versions de RHEL sont livrées tous les 18 à 24 mois. Quand Red Hat fournit une
nouvelle version de RHEL, les clients peuvent mettre à jour leur version gratuitement à condition
d'avoir un abonnement en cours.

Toutefois, les restrictions sur la marque déposée ne permettent pas la copie et la redistribution
de la distribution complète [Net3].

Stage d’Eté 16
 Ecole Nationale des Sciences de l’Informatique GL Trade

2.2.Shell Unix

Pour parvenir à bien développer cette application, c’est le Shell Unix qui sera utilisé vu la
variété des commandes qu’il offre.
[http://www.commentcamarche.net/linux/linshell.php3]
L'interpréteur de commandes est l'interface entre l'utilisateur et le système d'exploitation, d'où
son nom anglais «shell», qui signifie «coquille».

Le shell est ainsi chargé de faire l'intermédiaire entre le système d'exploitation et l'utilisateur
grâce aux lignes de commandes saisies par ce dernier. Son rôle consiste ainsi à lire la ligne de
commande, interpréter sa signification, exécuter la commande, puis retourner le résultat sur les
sorties.

Le shell est ainsi un fichier exécutable chargé d'interpréter les commandes, de les transmettre
au système et de retourner le résultat. Il existe plusieurs shells, les plus courants étant sh (appelé
«Bourne shell»), bash («Bourne again shell»), csh («C Shell»), Tcsh («Tenex C shell»), ksh («Korn
shell») et zsh («Zero shell»). Leur nom correspond généralement au nom de l'exécutable.

Chaque utilisateur possède un shell par défaut, qui sera lancé à l'ouverture d'une invite de
commande. Le shell par défaut est précisé dans le fichier de configuration /etc/passwd dans le
dernier champ de la ligne correspondant à l'utilisateur. Il est possible de changer de shell dans une
session en exécutant tout simplement le fichier exécutable correspondant, par exemple : /bin/bash
[Net4].

2.3.Shell utilisant Expect

Un autre type de scripts Shell a été utilisé lors de la phase de développement : ce sont les
scripts utilisant Expect.
[Translation basée sur le man de linux (man expect)]
Expect est un programme qui "parle" à d'autres programmes interactifs selon un script.
Suivant ce dernier, Expectsait à quoi s'attendre d'un programme et ce que la bonne réponse devrait
être. Un langage interprété prévoit des structures de branchement et de contrôle de haut niveau
pour diriger le dialogue. En outre, l'utilisateur peut prendre le contrôle et interagir directement à la
demande, et après, rendre le contrôle au script. Expect est basée sur TCL.

Stage d’Eté 17
 Ecole Nationale des Sciences de l’Informatique GL Trade

Le nom «Expect» provient de l'idée d'envoyer ou de s'attendre à (send/expect) des séquences,

popularisée par uucp, kermit et d'autres programmes de contrôle du modem. Mais contrairement à
uucp, Expect est généralisé afin qu'il puisse être exécuté avec n'importe quel programme et
n'importe quelle tâche. Expect peut en fait parler à plusieurs programmes en même temps.

En général, Expect est utile pour faire fonctionner n'importe quel programme qui requiert une
interaction entre le programme et l'utilisateur. Ce qui est important est que l'interaction peut être
caractérisée par programmation. Expect peut également rendre le contrôle à l'utilisateur (sans
arrêter le programme étant contrôlé) s'il le souhaite. De même, l'utilisateur peut redonner le contrôle
au script à tout moment (Cette partie est à la base une traduction du manuel de expect sous Linux).

Trois commandes sont au cœur de la puissance de expect : send, expect et spawn. La

commande send prend une chaîne comme argument et l’envoie à un processus. Par exemple :
send "hello world"
Cette commande envoie la chaîne hello world. Si expect est déjà en interaction avec un logiciel, la
chaîne sera envoyée à ce programme. Mais initialement, send l’envoie à la sortie standard.

La commande expect est l’opposé de send. Elle attend une réponse qui provient
habituellement d’un processus. La commande expect peut s’attendre à une chaîne bien spécifique,
mais plus souvent expect est utilisée pour s’attendre à toute chaîne qui correspond à un motif donné.

La commande spawn lance un autre programme. Un programme en cours d’exécution est

connu comme un processus. Expect est flexible et reconnait les humains comme des processus ce
qui nous permet d’utiliser les mêmes commandes pour les humains et les processus. La seule
différence est que les processus doivent d’abord être lancés et c’est ce que fait la commande spawn.
Le premier argument de la commande spawn est le nom du programme a lancé. Les autres
arguments sont passés à ce dernier [Net5].

Ci-dessous un exemple utilisant le programme Expect :

Stage d’Eté 18
 Ecole Nationale des Sciences de l’Informatique GL Trade

Figure 2 : Exemple de script utilisant le programme Expect

Dans cet exemple, la commande scp est lancée. Le système renvoie une chaîne se terminant
par « password : ». Ensuite, il y a envoie du mot de passe au système qui après vérification, renvoie
le prompt.

2.4.Cron et Crontab

Cron et Crontab jouent un rôle primordial dans l’automatisation de la synchronisation des

environnements distants.

➢ Cron

Cron est le nom d'un programme qui permet aux utilisateurs des systèmes Unix d'exécuter
automatiquement des scripts, des commandes ou des logiciels à une date et une heure spécifiées à
l'avance, ou selon un cycle défini à l'avance. Le nom est dérivé du grec chronos (χρόνος), signifiant
le temps.

Il s'agit d'une fonctionnalité très utile pour des tâches routinières d'administration système,
mais elle peut très bien être exploitée pour tout autre chose. Par exemple, on peut demander à cron

Stage d’Eté 19
 Ecole Nationale des Sciences de l’Informatique GL Trade

de jouer tel fichier mp3 tous les jours à sept heures sauf le samedi et le dimanche afin de se réveiller
en musique.

Cron est un démon (daemon), ce qui ─ dans le jargon Unix ─ désigne un programme qu'on ne
lance qu'une seule fois après le démarrage de l'ordinateur et qui reste en tâche de fond en attendant
qu'on ait besoin de lui. Le démon cron (crond) attend ainsi jusqu'au moment spécifié dans le fichier
de configuration (que l'on appelle la crontab) puis effectue l'action correspondante et se rendort
jusqu'à l'événement suivant.

Le démon cron est lancé par le compte root. Si on le tue (par la commande kill), il est
automatiquement relancé par le système [Net6].

➢ Crontab

Crontab est le nom du programme sous Unix (ou Linux) qui permet d'éditer des tables de
configuration du programme cron. La commande crontab édite en fait un fichier relatif à
l'utilisateur qui l'exécute, et en vérifie la syntaxe. Ce fichier se situe dans l'arborescence /var, par
exemple :
/var/spool/cron/crontabs/utilisateur (AIX, HP-UX, Debian GNU/Linux et Ubuntu)
/var/spool/cron/tabs/utilisateur (SuSE GNU/Linux)
/var/cron/tabs/utilisateur (FreeBSD et OpenBSD)
Ainsi pour l'utilisateur root sur une machine Debian, la table cron sera stockée dans :
/var/spool/cron/crontabs/root

Certains systèmes Linux (SuSE, Debian, RedHat) disposent en plus d'une crontab centralisée
dans /etc/crontab. Sur SuSE, on trouve également /etc/cron.d, /etc/cron.hourly, /etc/cron.daily,
/etc/cron.weekly et /etc/cron.monthly [Net7].

Pour lancer crontab et configurer crond, il suffit de taper : crontab -e et on tombe sur un écran
vi. Les paramètres sont pris en compte dès que l'on quitte vi. Les lignes de crontab sont de deux
genres : des commandes cron qui sont les commandes système à exécuter et à quel moment, et des
(re)définitions de variables d'environnement. On donne ligne par ligne les commandes à exécuter.
Les lignes ont le format suivant :
moment commande

Les commandes sont tout simplement celle que l'utilisateur taperait s'il les exécutait lui-même.
Stage d’Eté 20
 Ecole Nationale des Sciences de l’Informatique GL Trade

Un moment se décompose en 5 champs :

➢ Minute : 0 – 59
➢ Heure : 0 -23
➢ Jour du mois : 1 – 31
➢ Mois : 1 – 12
➢ Jour de la semaine : 0 – 7 (0 et 7 pour dimanche)

Pour chaque unité de temps (minute/heure/...) les notations possibles sont :

➢ * : a chaque unité de temps
➢ 2-5 : les unités de temps (2,3,4,5)
➢ */3 : toutes les 3 unités de temps (0,3,6,...)
➢ 5,8 : les unités de temps 5 et 8

Chaque champ est séparé par un espace et plusieurs éléments du même type sont séparés par
des virgules (sans espace). Exemple sous Linux :
0,10,20,30,40,50 * 1 * 7 /usr/bin/test

Cette ligne signifie : "exécute /usr/bin/test toutes les 0, 10, 20... minutes de toutes les heures du
premier jour de chaque mois qui doit être un lundi (tous les ans)...". La combinaison est assez
étrange de par son sens, mais c'est relativement puissant. Le principe en gros est de ne paramétrer
que les éléments qui sont intéressants et de mettre une * pour les autres. Pour lancer test toutes les
minutes, il suffit de taper :
* * * * * /usr/bin/test

La plus petite fréquence avec laquelle on exécute une commande est donc de 1 minute.

Les lignes de crontab permettent aussi de (re)définir des variables d'environnement pour
l'exécution des commandes cron. Cela se fait très simplement :
VARIABLE=VALEUR

Cela va attribuer la valeur VALEUR à la variable d'environnement VARIABLE.

Le shell utilisé sous Red Hat Entreprise Linux est bash (Bourne Again Shell). Pour que les
variables d’environnement définies dans le chapitre précédent soient prises en compte à chaque fois
qu’on lance le terminal ou qu’on exécute un script, elles ont été définies dans le fichier
$HOME/.bashrc, sauf que ce fichier n’est pas lu avant l'exécution des commandes par cron. Cela

Stage d’Eté 21
 Ecole Nationale des Sciences de l’Informatique GL Trade

peut entraîner des comportements étranges des scripts et difficiles à comprendre. Pour résoudre le
problème, il faut sourcer ce fichier avant de lancer la commande. Par exemple [Net8]:
* * * * * . $HOME/.bashrc; /usr/bin/test
X- Tests et validation

Plusieurs tests ont été effectués pour vérifier le bon fonctionnement de notre application en ce
qui concerne la génération des listes de fichiers, ainsi qu’à la connexion au serveur distant et le
transfert de fichiers entre les deux serveurs. D’autres tests ont porté aussi sur le lancement
automatique et le bon fonctionnement du programme cron.
XI- Chronogramme du projet

La figure ci-dessous représente les durées des différentes tâches effectuées pendant ce projet
durant la période de sept semaines.

N°Semaine 1 2 3 4 5 6 7

Documentation
Spécification
conception
réalisation
Test et validation
Rédaction du rapport

Figure 3 : Le chronogramme du projet

Stage d’Eté 22
 Ecole Nationale des Sciences de l’Informatique GL Trade

XII- Conclusion

Suite à la présentation de ces outils et ces notions qui permettrons de mieux comprendre le
fonctionnement de l’application, nous allons maintenant entamer la phase d’analyse et spécification.

Stage d’Eté 23
 Ecole Nationale des Sciences de l’Informatique GL Trade

Conclusion générale

Ce projet d’été s’est déroulé au sein de la société GL Trade. Il a pour objectif la

synchronisation d’environnements de développement distants (Londres/Tunis).

Ce projet a été une bonne occasion pour approfondir pour mettre en pratique mes
connaissances concernant le système d’exploitation Linux et de les approfondir encore plus en
exploitant d’autres techniques et outils de développement tels que la manipulation des crontab et
l’utilisation du programme expect.

D’autre part, ce projet a constitué une bonne occasion d’intégrer le milieu professionnel
puisqu’il représente ma première expérience au sein d’un établissement professionnel autre que
l’ENSI ce qui m’a fait découvrir davantage le travail au sein d’un groupe.

Enfin, l’application réalisée reste un point de départ qui laisse des grandes possibilités
d’extension et d’amélioration surtout pour généraliser son fonctionnement aux serveurs de toutes les
filiales de GL Trade et ne plus se contenter de l’employer entre le serveur de Londres et celui de
Tunis seulement.

Stage d’Eté 24
 Ecole Nationale des Sciences de l’Informatique GL Trade

Neto graphie

[Net1] http://virologie.free.fr/documents/openSSH/ssh_introduction.html

[Net2] http://www.cam.ac.uk/cs/filetransfer/compare.html

[Net3]http://fr.wikipedia.org/wiki/Red_Hat_Enterprise_Linux

[Net4]http://www.commentcamarche.net/linux/linshell.php3

[Net5] http://oreilly.com/catalog/expect/chapter/ch03.html

[Net6] http://fr.wikipedia.org/wiki/Cron

[Net7] http://fr.wikipedia.org/wiki/Crontab

[Net8] http://www.themanualpage.org/unix/cron.php

Stage d’Eté 25
 Ecole Nationale des Sciences de l’Informatique GL Trade

TABLE DES MATIERES

INTRODUCTION.................................................................. ........1

CHAPITRE 1 : PRÉSENTATION GÉNÉRALE.............................. ........2

I- Introduction.............................................................................................2

II- Présentation de l’organisme d’accueil.......................................................2

1. GL Trade................................................................................................ ...................2
2. GL Trade MENA.......................................................................................... ...............3

III- Présentation du sujet............................................................................4

IV- Conclusion............................................................................................4

CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS...............5

I- Etude de l’existant et solution retenue......................................................5

1. Etude de l’existant...................................................................... .............................5
2. Solutions envisagées..................................................................................... ...........5
3. Solution retenue.......................................................................................... .............6

II- Besoins fonctionnels................................................................................6

III- Besoins non fonctionnels.......................................................................7

IV- Conclusion............................................................................................7

CHAPITRE 3 : CONCEPTION DU LOGICIEL................................ ......8

I- Conception générale................................................................................8

II- Conception détaillée...............................................................................11

III- Conclusion..........................................................................................15

CHAPITRE4: RÉALISATION............................................. ............16

I- L’environnement de développement........................................................16
1. Environnement matériel :........................................................................... ............16
2. Environnement logiciel............................................................................ ...............16
2.1. Red Hat Entreprise Linux............................................................. ....................16
2.2. Shell Unix............................................................................. ...........................17
2.3. Shell utilisant Expect.................................................................... ...................17

Stage d’Eté 26
 Ecole Nationale des Sciences de l’Informatique GL Trade

2.4. Cron et Crontab............................................................................ ...................19

II- Tests et validation..................................................................................22

III- Chronogramme du projet.....................................................................22

IV- Conclusion..........................................................................................23

CONCLUSION GÉNÉRALE....................................... ....................24

NETO GRAPHIE........................... .............................................25

Stage d’Eté 27
 Ecole Nationale des Sciences de l’Informatique GL Trade

TABLE DES FIGURES

Figure 1: Implantations géographiques de GL Trade dans le monde......................3
Figure 2 : Exemple de script utilisant le programme Expect................................19
Figure 3 : Le chronogramme du projet.................................................................22

Stage d’Eté 28