Rapport Projet de fin d'etude sur le parc informatique

Mémoire de Fin d’Etudes
Pour l’obtention du diplôme
D’Ingénieur d’Etat
Génie Informatique
Promotion 2013 – 2014
Développement d’une application
de gestion d’un parc informatique
M. Hicham BENMOUSSA
Soutenance le 26 Juin 2014
Membres de jury :
M. Souhail CHELBAT Encadrant Société
M. Youness TABII Encadrant ENSATé
M. Mohamed LAZAAR Enseignant ENSATé
M. Mohamed CHRAYEH Enseignant ENSATé
Année Universitaire : 2013-2014

Remerciements
Il m’est agréable de m’acquitter d’une dette de reconnaissance auprès de toutes
les personnes, dont l’intervention au cours de mon stage, a favorisé son
aboutissement.
Ainsi, j’exprime ma profonde gratitude et je tiens à remercier M. Safi Mustafa de
m’avoir accordé l’opportunité de passer mon stage de fin d’études au sein de la
société ADDLOG.
Je remercie aussi infiniment toutes les personnes qui m’ont aidées à m’intégrer
au sein de la société et qui m’ont encadrées tout au long de mon stage parleurs
directives précieuses, conseils pertinents, à citer M. CHELBAT Souhail mon
encadrent société, EL BAKKALI Mohamed qui m’ont accompagnés durant le
stage au sein de la société et Mr ACHRAK Mehdi qu’y a permis, en grande partie,
de trouver ce stage.
Sans oublier M. TABII Youness, mon encadrant à l’école, auquel j’adresse tous
mes sentiments de reconnaissance les plus distingués.
Mes vifs remerciements s’adressent également aux membres du jury qui ont
accepté d’évaluer mon travail.
Enfin, j’espère que ce travail sera à la hauteur et pourra répondre aux attentes
et exigences auxquels il a été destiné.
BENMOUSSA Hicham

Résumé
Dans le cadre de mon projet de fin d’études à l’Ecole Nationale des Sciences Appliquées de
Tétouan (ENSAT) et en vue de l’obtention du titre d’ingénieur d’état en informatique, j’ai
effectué un stage de quatre mois à ADDLOG.
Durant mon séjour dans ladite société, j’avais pour mission dans un premier temps de concevoir
et de réaliser une application de gestion d’un parc informatique en suivant un cycle de vie qui
commence à l’étape de la conception/production/création jusqu'à la publication finale dans le
parc informatique en passant par les étapes de la vérification, de la validation et de
l’approbation. Dans un deuxième temps, j’étais amené à intégrer mon application dans le portail
interne de la société et assurer son opérabilité avec les différentes applications de son système
d’information.
Mon projet suit le model de cycle de vie en V, l’utilisation du formalisme UML pour la
réalisation de l’ensemble de diagrammes et enfin la modélisation MERISE puisqu’on nécessite
une base de données robuste, vise à détourner le problème. Ainsi, au terme de ce projet, j’ai pu
:
• Etablir une étude fonctionnelle et technique globale qui servira par la suite à continuer la
réalisation du système de gestion de parc informatique.
• Intégrer l’application dans le système d’information de la société

Liste des figures
Figure 1 : l’organigramme de la société ADDLOG .................................................................4
Figure 2 : les marques des matériels de la société ADDLOG ..................................................7
Figure 3 : les marques des matériels réseaux de la société ADDLOG......................................7
Figure 4 : Le model de cycle de vie en V ................................................................................9
Figure 5 : Diagramme de gant.................................................................................................9
Figure 6 : La navigation dans l'application............................................................................14
Figure 7 : Diagramme des cas d'utilisations de l'application..................................................18
Figure 8 : Diagramme de séquence du processus de visualisation des matériels ....................20
Figure 9 : fenêtre du cas d’utilisation ‘Consulter les matériels’ .............................................21
Figure 10 : Diagramme de séquence du processus de l’affichage des matériels achetés dans
une période...........................................................................................................................22
Figure 11 : fenêtre du cas d’utilisation ‘Afficher les matériels achetés dans une période’......23
Figure 12 : Diagramme de séquence du processus de l’ajout d’un nouveau matériel .............24
Figure 13 : fenêtre du cas d’utilisation ‘ ajouter un nouveau matériel ’..................................25
Figure 14 : Diagramme de séquence du processus de la modification du logiciel ..................26
Figure 15 : fenêtre du cas d’utilisation ‘ modifier un logiciel ’ ..............................................27
Figure 16 : Diagramme de séquence du processus de la création d’un groupe et la
modification de ses droits .....................................................................................................28
Figure 17 : fenêtre du cas d’utilisation ‘ gestion des groupes d’utilisateurs ’ .........................29
Figure 18 : Diagramme de séquence du processus de la visualisation l’historique des
connexions d’un utilisateur ………………………………………………………………...30
Figure 19 : fenêtre du cas d’utilisation ‘ gestion des connexions des utilisateurs ’ .................31
Figure 20 : schéma de l’architecture technique de l’application du parc ................................33
Figure 21 : diagramme d’activité ‘ Gestion des logiciels ’.....................................................34
Figure 22 : diagramme d’activité ‘ Gérer les utilisateurs ’.....................................................35
Figure 23 : diagramme d’activité ‘ Gérer les droits d’accès ’.................................................36
Figure 24 : diagramme d’activité ‘Attribuer un utilisateur à une machine ’ ...........................37
Figure 25 : diagramme d’activité ‘Rechercher un matériel ’..................................................38
Figure 26 : Le modèle logique des données du l’application .................................................39
Figure 27 : la table ‘ Société ’...............................................................................................40
Figure 28 : la table ‘ Département ’......................................................................................40

Figure 29 : la table ‘ Service ’...............................................................................................41
Figure 30 : la table ‘ Utilisateur ’..........................................................................................41
Figure 31 : la table ‘ Matériel ’ .............................................................................................42
Figure 32 : la table ‘ Machine ’.............................................................................................43
Figure 33 : la table ‘ Accessoire ’ .........................................................................................43
Figure 34 : la table ‘ Fournisseur ’ ........................................................................................44
Figure 35 : la table ‘ Logiciel ’..............................................................................................44
Figure 36 : la table ‘ Loueur ’ ...............................................................................................45
Figure 37 : la table ‘ Contrat ’...............................................................................................45
Figure 38 : la table ‘ paramètre ’...........................................................................................46
Figure 39 : la table ‘ Réparateur ’ .........................................................................................46
Figure 40 : la table ‘ Demande intervention ’ ........................................................................47
Figure 41 : Environnement WinDev .....................................................................................48
Figure 42 : Architecture logicielle.........................................................................................52
Figure 43 : Avantages de Méthode RAD...............................................................................54
Figure 44 : Evolution d’un projet avec la méthode RAD.......................................................55
Figure 45 : Parallélisassions et sérialisation des phases de projet avec la méthode RAD. ......56
Figure 46 : HyperFileSQL ....................................................................................................60
Figure 47 : logo du logiciel Edraw MAX..............................................................................64
Figure 48 : Logo du l’atelier génie logiciel WinDev 18.........................................................65
Figure 49 : fenêtre d’authentification....................................................................................66
Figure 50 : fenêtre compte administrateur.............................................................................66
Figure 51 : fenêtre de l’administration des utilisateurs et les groupes ....................................67
Figure 52 : fenêtre de l’ajout d’un nouvel utilisateur.............................................................68
Figure 53 : fenêtre de la gestion des droits ............................................................................69
Figure 54 : paramétrage des droits pour la fenêtre ‘ Fiche département ’...............................69
Figure 55 : fenêtre des statistiques de connexion de l’application..........................................70
Figure 56 : fenêtre des statistiques de connexion de l’application..........................................70
Figure 57 : fenêtre principale de l’application.......................................................................71
Figure 58 : Alerte de l’expiration de la garantie d’un matériel...............................................72
Figure 59 : La liste des entreprises et la fiche de création d’une nouvelle entreprise..............72
Figure 60 : La liste des utilisateurs (employeurs) et la fiche de création d’un nouvel employé
.............................................................................................................................................73
Figure 61 : La liste des matériels et la fiche d’ajout d’un nouvel matériel .............................74

Figure 62 : Rechercher un matériel .......................................................................................75
Figure 63 : La liste des logiciels et la fiche d’ajout d’un nouvel logiciel................................75
Figure 64 : La liste des machines (poste de travail) et la fiche d’ajout d’une nouvelle machine
.............................................................................................................................................76
Figure 65 : Architecture MVC..............................................................................................80
Figure 66 : Différence entre la théorie (les spécifications) et la pratique (ce qui a été produit)
.............................................................................................................................................85

Liste des tableaux
Tableau 1 : références et partenaires de la société ADDLOG ..................................................6
Tableau 2 : Acteurs du système ............................................................................................15
Tableau 3 : Répartition des rôles en fonction des étapes........................................................84
Tableau 4 : Documents en fonction des étapes......................................................................85

Sommaire
Introduction............................................................................................................................1
Chapitre 1 : Contexte général du projet.................................................................................3
1. Présentation de l’organisme d’accueil............................................................................3
1.1 La société ADDLOG :............................................................................................3
1.2 L’organigramme de la société :...............................................................................4
1.3. Les objectifs : ........................................................................................................4
1.4. Les activités :.........................................................................................................5
1.5. Produits :...............................................................................................................6
1.6. Les références et partenaires :................................................................................6
1.7. Les marques représentées : ....................................................................................7
2. Présentation du projet : objectifs et champ d’application................................................8
2.1. Présentation du projet ............................................................................................8
2.2. La démarche suivie................................................................................................8
Chapitre 2 : Etude et spécification des besoins....................................................................13
1. La navigation dans l’application ..................................................................................13
2. Identification des acteurs .............................................................................................14
3. Scénarios.....................................................................................................................15
3.1. Actions du fonctionnaire......................................................................................15
3.2. Actions du magasinier .........................................................................................15
3.3. Actions du comptable ..........................................................................................16
3.4. Actions du responsable........................................................................................16
3.5. Actions du superviseur ........................................................................................17
4. Les cas d’utilisation du système...................................................................................17
4.1. Cas d’utilisation ‘ Consulter les matériels et les logiciels ’...................................19
4.2. Cas d’utilisation ‘Afficher les matériels achetés dans une période ’ .....................21
4.3. Cas d’utilisation ‘ ajouter un nouveau matériel ’..................................................23
4.4. Cas d’utilisation ‘ modifier un logiciel ’...............................................................25

4.5. Cas d’utilisation ‘ gestion des groupes d’utilisateurs ’..........................................27
4.6. Cas d’utilisation ‘ gestion des connexions d’un utilisateur ’ .................................29
Chapitre 3 : Conception ......................................................................................................32
1. Stratégie de développement .........................................................................................32
2. Architecture technique de l’application........................................................................32
3. Comportement dynamique de l’application..................................................................34
3.1. Gestion des logiciels............................................................................................34
3.2. Gérer les utilisateurs............................................................................................34
3.3. Gérer les droits d’accès........................................................................................35
3.4. Attribuer un utilisateur à une machine .................................................................36
3.5. Rechercher un matériel........................................................................................37
4. Description de la base de données................................................................................38
4.1. Le modèle logique des données du l’application (MLD) ......................................38
4.2. Description des tables..........................................................................................40
Chapitre 4 : Etude technique du projet ................................................................................48
1. L’environnement WinDev ...........................................................................................48
1.1 Présentation WinDev............................................................................................48
1.2 Argumentaires généraliste WINDEV....................................................................49
1.3 Que fait-on avec WinDev .....................................................................................49
1.4 L’argumentaire technique .....................................................................................50
1.5 Argumentaire Base de Données ............................................................................50
1.6 Argumentaire réactivité et vitesse de développement ............................................51
2. Architecture et outils ...................................................................................................51
2.1 Architecture logicielle du système ........................................................................51
2.2 Choix des langages et outils..................................................................................53
2.3 Système de gestion de la base de données relationnelle.........................................58
Chapitre 5 : mise en œuvre du projet...................................................................................62
1. Présentation.................................................................................................................62

2. Réalisation de la solution.............................................................................................63
2.1 La couche Données : ............................................................................................63
2.2 La couche Mapping et Persistance : ......................................................................63
5.3 La couche Métier :................................................................................................63
5.4 La couche Services :.............................................................................................63
5.5 La couche Présentation :.......................................................................................63
3. Développement : .........................................................................................................63
3.1 Outils de développement : ....................................................................................63
3.2 Environnement de modélisation Edraw :...............................................................64
3.3 Environnement de développement WinDev ..........................................................65
4. Présentation de quelques interfaces..............................................................................65
Conclusion et perspectives....................................................................................................77
Bibliographie........................................................................................................................78
Webographie ........................................................................................................................79
Annexe 1 : Le Design Pattern MVC....................................................................................80
1. Le design pattern MVC ...............................................................................................80
1.1. Architecture MVC...............................................................................................80
2. Avantages et inconvénients..........................................................................................81
Annexe 2 : Le cycle de vie en V .........................................................................................83
1. Définition....................................................................................................................83
2. Les étapes....................................................................................................................83
3. Rôles ...........................................................................................................................83
4. Documents par phase...................................................................................................84
5. Risques inhérents au Cycle en V..................................................................................85
6. Comité de pilotage.......................................................................................................86

1 Développement d’une application de gestion d’un parc informatique
Introduction
La plupart des organisations possèdent aujourd’hui un réseau d'ordinateurs privé. Au travers de
ce réseau, les postes échangent des fichiers, partagent des imprimantes et parfois utilisent des
applicatifs (logiciels) en commun.
De nos jours, la plupart des applicatifs de gestion ont une architecture client-serveur (les
données sont sur le serveur qui assume l’essentiel du travail, le client ne fait qu’envoyer des
requêtes). Ces applicatifs constituent le cœur de ce que l'on appelle le système d'information
central.
Ces applicatifs gèrent des plannings, des annuaires, des ressources, des stocks, des commandes,
des livraisons, etc. Ce qui permet de mettre facilement à la disposition des employés des
documents divers et variés et oblige un accès centralisé à la mémoire de l'entreprise. Il est donc
généralement nécessaire de définir des droits d'accès pour les utilisateurs de l'intranet et par
conséquent une authentification de ceux-ci afin de leur permettre un accès personnalisé aux
fonctionnalités assurées par l’intranet.
De cette façon, un intranet favorise la communication au sein de l'entreprise et limite les erreurs
dues à la mauvaise circulation d'une information.
Au sein de la société ADDLOG, ma mission était de choisir un portail répondant à ses exigences
et le mettre en place. L’application de la Gestion de parc informatique après avoir été conçue
et développée doit s’intégrer dans ce portail avec l’ensemble des applications du système
d’information de la société. En effet, La gestion de parc permet de suivre en temps réel du
patrimoine informatique, matériel et logiciel de l’entreprise. Elle offre une vision globale de
l’état, du suivi et des coûts des appareils utilisés dans l’entreprise et de bien Gérer les différents
types d’équipements (Unités Centrales, Ecrans, Imprimantes, Matériels Réseaux, Matériels non
informatiques) ainsi que leurs Composants Hard et Soft (Processeurs, Mémoires, Disques durs,
OS, Logiciels…) et aussi visant à assurer le bon fonctionnement des PC et serveurs.
Le présent rapport décrit les différentes étapes de la réalisation du projet. Il comporte cinq
chapitres. Le premier chapitre définit le contexte général du projet et se compose de deux
parties. La première donne une présentation de la société au sein de laquelle j’ai effectué mon
stage. Quant à La deuxième partie, elle est consacrée à la présentation du projet et ses objectifs.
Le deuxième chapitre présente l’ensemble des spécifications du projet pour faire l’inventaire
des différentes fonctionnalités du système à réaliser. Le troisième chapitre présente la phase
conceptuelle du projet. L’étape de l’étude technique de l’application fait l’objet du quatrième
chapitre, celle-ci dresse l’environnement dans lequel s’inscrit l’application ainsi que le choix

du portail résultant d’une étude comparative passant au crible un ensemble de portails répondant
aux exigences de la société. Enfin, le cinquième chapitre est consacré à la phase de la réalisation
et la mise en œuvre du système. Il est constitué de deux parties, à savoir la partie réalisation
dans laquelle on a décrit les outils que j’ai manipulés et la partie de la mise en marche de
l’application qui présente quelques interfaces.
Ce rapport se termine par une conclusion contenant quelques perspectives pour le système de
gestion d’un parc informatique.
En complément, on présente les différentes annexes qui serviront pour élargir la portée du projet
tout en restant dans son environnement, à savoir la suite des spécifications du système, ainsi
que quelques annexes traitant l’aspect technique et organisationnel du projet.

3 Chapitre 1 : Contexte général du projet
Chapitre 1 : Contexte général du projet
Dans ce chapitre je présente l'organisme d'accueil ADDLOG où s'est déroulé mon projet de fin
d’études. Ensuite, je définis la problématique et les objectifs escomptés par le projet.
1. Présentation de l’organisme d’accueil
1.1 La société ADDLOG :
Crée en 2004 par une équipe d’ingénieurs polyvalents ayant tous la volonté d’accompagner les
entreprises du Nord Ma roc au cours de leur développement en matière des nouvelles
technologies. En fait, elle préfère la dénomination « partenaires » pour désigner les entreprises
qui lui font confiance pour les aider à s’adapter aux mutations constantes des nouvelles
technologies de l’information.
Aujourd’hui, elle a l’honneur d’affirmer sa réussite d’exposer cette vision à un grand nombre
de partenaires, ce qui lui donne la passion d’être présent à côté du client pour être toujours à la
hauteur des attentes.
Pour cela, elle n’épargne aucun effort, et surtout pas celui de former et d’assister leur
collaborateurs et partenaires.

1.2 L’organigramme de la société :
Figure 1 : l’organigramme de la société ADDLOG
1.3. Les objectifs :
Dans le cadre de sa vocation, ses objectifs sont :
 Améliorer la position de ses clients sur un marché globalisé, en gagnant les défis qui
leur permettent d’augmenter leur compétitivité ainsi que leurs perspectives de chiffre
d’affaire.
 Combiner son expérience avec ses ressources humaines de qualité pour innover et
améliorer notre service client continuellement.

1.4. Les activités :
1.4.1. Réseaux et Systèmes :
La configuration des réseaux est le point de départ de son service. Elle examine la situation
initiale du client et concevra une infrastructure de réseaux qui s’ajuste à leur besoins.
En tant que Partners certifiés de Cisco Systems, DELL et Microsoft et dans le cadre d’un suivi
constant de l’évolution des nouvelles technologies, elle possède d’amples connaissances sur les
environnements suivants :
 Systèmes opérationnels Linux et Windows
 Conception, installation et extension des réseaux informatiques.
 Pose et installation de la fibre optique
 Conception et installation des salles de serveurs et des équipements en Rack.
 Equipement des salles de réunion par des systèmes de projection et D’audioconférence.
 Système téléphonique analogique et solution VOIP.
 Interconnexion des réseaux distants d’entreprises
 Système de pointage.
 Vidéosurveillance et système anti-intrusion.
1.4.2. Serveurs :
Les serveurs disponibles dans la société ADDLOG sont :
 Serveurs de messagerie (Microsoft Exchange server)
 Serveurs de fichier et de partage avec une gestion d’accès aux ressources partagées.
 Pare-feu et solutions de filtrage entrant /Sortant
 Serveurs de backup pour des systèmes critiques.
1.4.3. Prestation de services et Maintenance
Pour répondre aux exigences de ses clients, elle se base sur la compétence de son équipe
technique, certifiée CISCO networks et Microsoft Systems, ainsi que sur l’expérience qu’elle a
acquis dans ce domaine en travaillant avec des entreprises de grande envergure (la liste après
ci-dessous), ainsi elle accompagne ses activités par quelque services pour mieux servir le
client :
 Service après-vente.
 Maintenance informatique par intervention ou sous contrat de maintenance
 Location des équipements : Imprimantes, photocopieurs ….

1.5. Produits :
Les produits de la société varient beaucoup ce qui lui donne un avantage dans le marché. Voici
une liste des produits et services de cette société :
 Vente de Matériel Informatique :
La société propose au client une large gamme de solution et de produits informatiques comme
: DELL, FUJITSU SIEMENS, HP, IBM, CIS CO, CANON, LEXMARK, XEROX, …
 Systèmes de pointage et gestion de personnels :
Marque représentée : ACRONYM
 Vidéosurveillance, Systèmes d’alarme et détection d’intrusion :
Marque représentée : TEXECOM, JABLOTRON
 Standard téléphonique et système VOIP :
Marque représentée : NORTEL NETWORKS, LG-NORTEL Alcatel, Siemens, Système VOIP
basé sur ASTE RISK.
1.6. Les références et partenaires :
Voici la liste de quelques références et partenaires de la société ADDLOG (tableau 1 ci-
dessous)
AWSM1 COFICAB TAKATA TMSA Medi1TV SRPTM
RENAULT
MAROC
EADS
MAROC
NUCAIN JOBELSA
MAROC
ZIMED
CONSULTING
TREMSA
(San Jose
Lopez)
COFELY POLYDESIGN ARFADEL ADDOHA EUROGATE …
Tableau 1 : références et partenaires de la société ADDLOG

1.7. Les marques représentées :
Les marques des produits se varient beaucoup selon le besoin du client pour le satisfaire voici
une liste des marques au niveau matériel :
Et au niveau réseaux :
Figure 2 : les marques des matériels de la société ADDLOG
Figure 3 : les marques des matériels réseaux de la société ADDLOG

2. Présentation du projet : objectifs et champ d’application
Dans cette partie, je présente le projet, les objectifs s’inscrivant dans le cadre de ce dernier et le
champ d’application.
2.1. Présentation du projet
Au terme d’une réunion entre le directeur de la société, mon encadrent et moi-même, j’ai
convenu que la plus grande faiblesse du système d’information du ADDLOG était l’absence
d’inventaire du parc informatique.
Le projet a donc été définit comme la mise en place d’une solution de gestion de parc
informatique capable d’inventorier automatiquement ce dernier.
Ainsi, ADDLOG a exprimé un besoin pressant de mettre à niveau son système d’information
et d’adopter un système efficace et ouvert afin de remédier aux problèmes de la gestion du parc
informatique.
Le but de l’application de la gestion du parc informatique est :
• L’accès simple à l'information,
• Classification, enregistrement et archivage des matériels achetés ou loués,
• Gestion de la sécurité (droits d’accès aux fonctionnalités de l’application),
• Gain du temps,
• La gestion et la traçabilité de tous les processus de travail,
• Communication souple entre les machines
• L’évolutivité et l'anticipation des besoins futurs.
La première phase du présent projet était de comprendre l’objectif du sujet et d’arriver à
délimiter le champ de travail pour pouvoir intervenir par la suite de manière plus efficace.
C’est ainsi que les premières entrevues avec mon encadrant m’ont permises de bien cerner le
sujet dans son contexte et de dégager la problématique et les objectifs visés. Une fois que la
vision sur le projet s’est éclaircie, il m’a été possible d’énumérer les fonctionnalités et de définir
la méthodologie de travail et de faire la version préliminaire du projet et par la suite la version
finale.
2.2. La démarche suivie
2.2.1. Cycle de vie du projet
Le « cycle de vie d'un logiciel » (en anglais software lifecycle), désigne toutes les étapes du
développement d'un logiciel, de l’idée à sa disparition. L'objectif d'un tel découpage est de
permettre de définir des jalons intermédiaires permettant la validation du développement

logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés et la vérification du
processus de développement, c'est-à-dire l'adéquation des méthodes mises en œuvre.
L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus élevé
qu'elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de
détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa
réalisation et les coûts associés.
2.2.2. Approche, méthodologie et planning du projet
Le model du cycle de vie adopté pour la réalisation de ce projet est le model en V, la figure ci-
après (Figure 4) présente ce model sous ses différentes étapes :
Figure 4 : Le model de cycle de vie en V
L’ensemble des activités de ce model suivant le temps est :
Figure 5 : Diagramme de gant

 Etude de faisabilité et analyse des besoins :
Il s’agit du recueil et de la formalisation des besoins du client selon mon
encadrent dans la société (ADDLOG) et de l'ensemble des contraintes.
 documentation sur les parcs informatiques et l'étude de l'existant :
J’ai lit pas mal des articles sur les parcs informatiques comment ils fonctionnent,
les principaux composants … . Et aussi j’ai fait du benchmarking sur les
solutions libres et propriétaires des logiciels de gestion de parc informatique afin
de prendre des idées sur ma future application.
 Spécifications :
Il s'agit de l'élaboration des spécifications de l'architecture générale du logiciel.
Pendant laquelle j’ai décrit l’ensemble des cas d’utilisation du système avec
proposition des maquettes d’Interface Homme/Machine répondant aux besoins.
 Conception :
J’ai décrit dans cette étape l’ensemble des tables, objets et activités de
l’application et aussi la création du MCD après la génération du MLD du
l’application et ainsi la génération de la base de données.
 Codage :
La traduction dans le langage de programmation choisi des fonctionnalités
définies lors de la phase de la conception et j’ai réussi à développer l’application
en sa totalité sans la réviser et corriger les erreurs ou faire la gestion des
exceptions.
 Tests unitaire ,tests d’intégration et modification et correction des erreurs :
Permettant de vérifier individuellement que chaque sous-ensemble du logiciel
est implémenté conformément aux spécifications et
qu’il s’intégrera bien avec l’ensemble, et aussi la correction des erreurs
d’orthographes et faire la gestion des exceptions et de manipulation de
l’application
 Tests de validation et recette finale :
pour valider l’ensemble des spécifications du système conçu un test de validation
est requis , aussi la mise en place de l’application répondant au cahier des charges
défini.
2.2.3. Le méthode d’analyse et de modélisation MERISE :
La méthode Merise est une méthode d'analyse, de conception et de réalisation de systèmes
d'informations.

En amont, elle se situait dans le prolongement naturel d'un schéma directeur, souvent conduit
suivant la méthode RACINES, très présente notamment dans le secteur public.
Les projets Merise étaient généralement des projets de grande ampleur de refonte d'un existant
complexe, dans un environnement grand système. La méthode a aussi connu des tentatives
d'adaptation avec les SGBD relationnels, les différentes interfaces homme-machine IHM,
l'Orienté objet, le développement micro, les outils CASE, la rétro-ingénierie... mais qui n'ont
pas connu le même succès.
La méthode est essentiellement française. Elle a des équivalents à l'étranger en ce qui concerne
les modèles de données (avec des différences, par exemple les cardinalités ne sont pas aussi
détaillées dans les modèles anglosaxons). En revanche la modélisation des traitements est
beaucoup plus complexe que dans les méthodes anglo-saxonnes.
Sa mise en œuvre peut paraître lourde. On consacre beaucoup de temps à concevoir et à pré-
documenter avant de commencer à coder, ce qui pouvait sembler nécessaire à une époque où
les moyens informatiques n'étaient pas aussi diffusés qu'aujourd'hui. Cela dit, elle évite l'écueil
inverse du développement micro, qui souffre du manque de documentation, et où les erreurs
sont finalement très coûteuses à réparer a posteriori.
Même si les échanges et la consultation entre concepteurs et utilisateurs sont formellement
organisés, on a aussi reproché à Merise d'utiliser un formalisme jugé complexe (surtout pour
les modèles de données), qu'il faut d'abord apprendre à manier, mais qui constitue ensuite un
véritable langage commun, puissant et rigoureux pour qui le maîtrise.
L'articulation très codifiée et bien balisée des différentes étapes, avec un descriptif très précis
des résultats attendus est ce qui reste aujourd'hui de mieux connu et de plus utilisé.
Pour mon projet j’ai utilisé MERISE pour concevoir seulement la base de données puisque cette
application nécessite une base de données robuste.
2.2.4. Le langage de modélisation UML :
Dans le but de concevoir un système extensible, évolutif, modulaire et orienté objet, le
formalisme UML s’est imposé comme un outil performant afin d’élaborer ce projet. En effet,
le langage de modélisation UML permet de mener la phase de conception tout en bénéficiant
de la puissance et de la simplicité de ses diagrammes.
UML est un langage de modélisation de troisième génération, normalisé par l'OMG (Object
Management Group) début 1997. C'est une fusion des idées des méthodes Booch, OMT et
OOSE (Object Oriented Software Engineering). Il a été conçu pour servir de langage de
modélisation objet, indépendamment de la méthode de mise en œuvre.

UML définit 9 diagrammes pour donner à l’utilisateur les moyens de visualiser et de manipuler
des éléments de modélisation : diagrammes d’activités, diagrammes de cas d’utilisation,
diagrammes de classes, diagrammes de collaboration, diagrammes de composants, diagrammes
de déploiement, diagrammes d’états transitions, diagrammes d’objets et diagrammes de
séquences.
Le choix d’UML, comme outil de modélisation des flux et les différentes actions de
l’application, peut être justifié par plusieurs raisons :
• UML facilite la compréhension et la communication d’une modélisation objet,
• La notation UML s'impose comme un standard de fait à l'heure actuelle sur le marché,
• Il est adopté par les grands constructeurs de logiciel du marché,
• L’utilisation d’UML offre l’avantage de disposer de vues de haut niveau d'abstraction,
• Pour favoriser la communication entre utilisateurs, spécialistes et informaticiens.
Conclusion
Dans ce chapitre j’ai décrit le contexte général dans lequel s’inscrit le projet. Au début, j’ai
présenté l’entreprise d’accueil à savoir ADDLOG. Ensuite, j’ai déterminé la problématique et
les objectifs du projet qui se résument en la réalisation d’un système de gestion du parc
informatique. Après, j’ai présenté la démarche que j’ai suivie pour arriver à mon but et cela
par la présentation du processus de développement ou cycle de vie du projet que j’ai adopté en
l’occurrence le model en V. Puis, le formalisme merise pour la conception de la base de
données et aussi UML qui m’a servi de standard dans la réalisation des diagrammes de
modélisation relatifs à notre projet et ce, afin d’illustrer son fonctionnement.
Dans le chapitre suivant je présentera les spécifications du système.

13 Chapitre 2 : Etude et spécification des besoins
Chapitre 2 : Etude et spécification des besoins
Ce chapitre détaille les spécifications pour la réalisation de l’application de la ‘Gestion de
parc informatique’. Il décrit l’ensemble des cas d’utilisation du système avec des propositions
de prototypes d’Interfaces Homme/Machine (IHM) possibles pour l’application.
En effet, le présent chapitre définira les interactions entre le collaborateur et l’application de
la Gestion de parc informatique tout au long du cycle de vie des machines et des ordinateurs.
Ce dernier commence de la phase de remplissage de différentes domaines de l’application (par
exemple les utilisateurs, matériels, machines, réseaux …) en passant par les phases du
paramétrage de l’application, et enfin d’établir des opérations sur les ordinateurs et les
périphériques associés au réseau.
Ainsi pour assurer le suivi de l’état du parc, on pourra définir beaucoup de types des
utilisateurs : administrateurs, Magasinier, fonctionnaires, Comptables, réparateurs,
responsables d’achats, ….
1. La navigation dans l’application
La figure ci-après (Figure 6) décrit la navigation dans l’application Gestion de parc
informatique.

Figure 6 : La navigation dans l'application
(*) L’apparition des sous menu du menu principal varie selon l’utilisateur et ses droits
2. Identification des acteurs
Le tableau ci-après (Tableau 2) illustre les différents acteurs du système.

Tableau 2 : Acteurs du système
3. Scénarios
3.1. Actions du fonctionnaire
Le fonctionnaire est un collaborateur au sein du parc qui n’a pas des rôles supplémentaires dans
l’application. Ci-après ses actions possibles :
o Consulter les matériels et les logiciels
o Imprimer la liste des matériels selon un critère
o Rechercher un matériel ou logiciel
o Filtrer les données afin de voir les matériels achetés dans une période
o Imprimer des factures de l’achat du matériel ou logiciel
3.2. Actions du magasinier
Le magasinier est aussi un collaborateur au sein du parc, c’est-à-dire qu’il possède toutes les
actions citées précédemment en tant que fonctionnaire. De plus, il a des actions suivantes :
o Saisir les informations du matériel et du logiciel
o Mise à jour des informations sur les matériels et les logiciels (modification)
o Affectation d’un matériel ou logiciel à un utilisateur du parc
est un employé de la société qui va consulter les informations sur
des matériels et des logiciels du parc
Est la personne qui s’en charge de saisir les informations du
matériel ou logiciel entré en respectant des règles de gestion
précise
est responsable de l'administration financière du parc, il paie des
factures des fournisseurs et il est responsable de valider les
contrats de la société
Le rôle majeur est d’assurer l’évolution et la maintenance du par
cet aussi de donner l’accord d’acquisition du matériel ou du
logiciel et du staff
Est en charge du paramétrage de la base et il fait la gestion de
n’importe quelle composant du parc qui existe dans l’application
(matériel, logiciel, machine, utilisateur,….) etc.

o prêter du matériel aux utilisateurs du parc
o Récupérer le matériel déjà affecté
o Rédaction d’une commande
3.3. Actions du comptable
Le comptable est aussi un collaborateur au sein du parc, il a des actions concernant le
domaine de comptabilité. Ci-après ses actions :
o La gestion des contrats de location des matériels (création, modification, suppression)
o Consultation des informations sur les utilisateurs du parc
o Consulter le graphe de reporting concernant les matériels acheté depuis la création du
parc
o Affirmation de retour de garantie des matériels
o Ecrire une nouvelle intervention
o L’impression de : matériels en stock, les contrats de location, les retours en garantie…
3.4. Actions du responsable
Le responsable est aussi un collaborateur au sein du parc, c’est-à-dire qu’il possède toutes les
actions en tant qu’un magasinier et d’un fonctionnaire. De plus, il a des actions sur le parc
auxquels il a été désigné comme responsable. Ci-après ses actions :
o Gestion des utilisateurs du parc (ajouter, modifier, supprimer)
o Mettre une sauvegarde des données
o Récupération de données sauvegardées
o Afficher les statistiques de connexions dans une période selon un utilisateur de
l’application
o Effectuer les achats informatiques (matériels ou logiciels)
o Création d’une nouvel Intervention sur incident
o Gestion des postes de travail (machines)
o Gestion des fournisseurs
o Faire le suivi des pannes et des réparations
o Elaboration des besoins en matériel pour la maintenance
o Remise les matériels en différents états (affecté, intervention réparation, …)

3.5. Actions du superviseur
Le superviseur de l’application pourrait lui aussi être considéré comme étant un fonctionnaire,
magasinier et aussi d’un responsable au sein du parc. De plus, il a des actions supplémentaires
dans l’application. Ci-après ses actions :
o Création, modification, suppression des utilisateurs de l’application
o Gestion des groupes d’utilisateurs
o Mise hors service d’un matériel
o Gestion des départements et les services de la société
o Effacer les statistiques de connexions dans une période selon un utilisateur de
l’application
o Gestion des réparateurs et des loueurs
o Paramétrage des alertes de différentes actions en cours
4. Les cas d’utilisation du système
Le diagramme ci-après (Figure 7) illustre les différents cas d’utilisation de l’application de la
Gestion du parc informatique résumant les différentes actions des acteurs, les sous parties
suivantes détailleront les plus importants cas d’utilisation de mon application ainsi que des
prototypes de fenêtres proposées.

Figure 7 : Diagramme des cas d'utilisations de l'application

4.1. Cas d’utilisation ‘ Consulter les matériels et les logiciels ’
4.1.1. Description du cas d’utilisation
Ce cas d’utilisation permet de voir les différents matériels et logiciels en vue de leur ajout dans
la base du parc informatique, dans cet exemple, je vais expliquer la partie matériel, la même
démarche s’applique sur les logiciels. Ci-après l’ensemble des informations sur ce cas
d’utilisation :
 Acteurs : Les acteurs pouvant consultés les matériels et les logiciels sont :
fonctionnaire, magasinier, responsable, superviseur de l’application
 Pré-conditions : l’authentification dans l’application.
 Action de départ : Accéder à l’application du parc.
 Enchaînement :
 Enter le nom d’utilisateur et le mot de passe
 La vérification du système si les informations sont correctes
 Si les informations sont erronées un message apparait qui dit que soit l’utilisateur
n’existe pas soit le mot de passe est incorrect, sinon il accède au menu principale
du l’application
 Dans le menu matériel il clique sur liste des matériels pour les visualiser
 Action de fin : quitter la fenêtre des matériels
 Post-conditions : Aucune
4.1.2. Diagramme de séquence
Le diagramme ci-après (Figure 8) illustre le processus de visualisation des matériels qui doit
être précédé par une authentification.

Figure 8 : Diagramme de séquence du processus de visualisation des matériels
4.1.3. Fenêtre de la liste des matériels
La figure ci-après (Figure 9) propose la fenêtre d’interface IHM pour la visualisation de la liste
des matériels.
Dans cette fenêtre l’acteur qui l’a accédé est le responsable car le fonctionnaire voit les
boutons : nouveau, modifier, supprimer grisés.

Le double clic sur un matériel affiche ses détails, le bouton ‘ fermer ’ pour clôturer la fenêtre et
revenir à la fenêtre principale.
4.2. Cas d’utilisation ‘Afficher les matériels achetés dans une période ’
Ce cas d’utilisation permet de voir les différents matériels achetés de la base du parc
informatique tel que la date d’achat est comprise entre deux dates saisies dans la fenêtre de
« les matériels achetés dans une période »,. Ci-après l’ensemble des informations sur ce cas
d’utilisation :
 Acteurs : Les acteurs pouvant consultés les matériels achetés dans une période sont :
fonctionnaire, magasinier, responsable, superviseur de l’application
 Enchaînement :
 L’authentification (vérification du nom d’utilisateur et mot de passe).
 L’accès au menu principale du l’application
 Dans le menu matériel il clique sur matériels achetés dans une période
 Saisir la date de début et la date de fin ou choisir une période déjà prédéfinie
 Clic sur le bouton Afficher les matériels
Figure 9 : fenêtre du cas d’utilisation ‘Consulter les matériels’

 Remplissage automatique de la table par les matériels qui répond au critère de la
recherche
 Action de fin : quitter la fenêtre des matériels
Le diagramme ci-après (Figure 10) illustre le processus de la recherche des matériels achetés
dans une période, bien sûr qui doit être précédé par une authentification.
Figure 10 : Diagramme de séquence du processus de l’affichage des matériels achetés
dans une période
4.2.3. Fenêtre de la liste des matériels
La figure ci-après (Figure 11) propose la fenêtre d’interface IHM pour la visualisation de la
liste des matériels achetés entre la date de début et la date de fin.
Dans cette fenêtre l’acteur qui l’a accédé est le fonctionnaire.

Le bouton ‘ Période prédéfinie ’ permet de dérouler une liste contient des différentes périodes
comme : semaine en cours, semaine flottante, mois en cours …
Le bouton ‘ Afficher les matériels ‘ affiche des informations dans la table selon la période saisie,
aussi en peut imprimer le résultat à l’aide du bouton ‘ Imprimer ‘ mais si la table est vide et on
veut imprimer le résultat, un message d’erreur s’affiche indiquant qu’il n’existe rien à imprimer.
4.3. Cas d’utilisation ‘ ajouter un nouveau matériel ’
Ce cas d’utilisation permet d’ajouter un nouveau matériel dans l’application. Ci-après
l’ensemble des informations sur ce cas d’utilisation :
 Acteurs : Les acteurs pouvant modifiés les logiciels sont : magasinier, responsable,
superviseur de l’application
 Enchaînement :
 Dans le menu matériel il clique sur création d’un nouveau matériel
 Remplir toutes les informations nécessaires
Figure 11 : fenêtre du cas d’utilisation ‘Afficher les matériels achetés dans une période’

 Clic sur le bouton Valider
 Vérification du système des champs obligatoires
 Renvoyer le message d’affirmation d’ajout du matériel
 Action de fin : quitter la fenêtre de la création d’un nouveau matériel
 Post-conditions : vérification du système du format des champs (date, email,
numéro,…)
Le diagramme ci-après (Figure 12) illustre le processus de l’ajout d’un nouveau matériel au
sein du l’application après avoir choisi le type et le modèle.
Figure 12 : Diagramme de séquence du processus de l’ajout d’un nouveau matériel
4.3.3. Fenêtre de l’ajout du matériel
La figure ci-après (Figure 13) propose la fenêtre d’interface IHM pour la création d’un nouvel
matériel.
Dans cette fenêtre l’acteur qui l’a accédé est le magasinier.

Figure 13 : fenêtre du cas d’utilisation ‘ ajouter un nouveau matériel ’
La case à cocher ‘Partager en réseau’ permet d’afficher le champ ‘Adresse IP’ pour renseigner
une adresse pour le matériel, si la case est décochée alors le champ ‘Adresse IP ’ est invisible.
Le sélecteur d’achat ou location permet de visualiser des champs selon le cas sélectionné, s’il
s’agit de la location les champs loueurs et le N° de contrat s’affiche sinon les autres champs qui
s’affichent (Figure 13)
4.4. Cas d’utilisation ‘ modifier un logiciel ’
Ce cas d’utilisation permet de mise à jour des informations sur u logiciel (augmenter le nombre
de licences, modifier l’éditeur,…). Ci-après l’ensemble des informations sur ce cas
d’utilisation :
 Acteurs : Les acteurs pouvant modifiés les logiciels sont : magasinier, responsable,
superviseur de l’application
 Enchaînement :

 Dans le menu logiciel il clique sur liste des logiciels
 Sélectionner un logiciel et cliquer sur le bouton modifier
 Mise à jour des champs concernés
 Vérification du système des formats des champs et aussi les champs obligatoires
 Message d’affirmation de la mise à jour des données du logiciel en cours
 Action de fin : quitter la fenêtre de la modification du logiciel
Le diagramme ci-après (Figure 14) illustre le processus de la mise à jour des informations sur
un logiciel, bien sûr qui doit être précédé par une authentification.
Figure 14 : Diagramme de séquence du processus de la modification du logiciel
4.4.3. Fenêtre de la modification du logiciel
La figure ci-après (Figure 15) propose la fenêtre d’interface IHM pour la visualisation de la
liste des matériels achetés entre la date de début et la date de fin.
Dans cette fenêtre l’acteur qui l’a accédé est le superviseur.

Figure 15 : fenêtre du cas d’utilisation ‘ modifier un logiciel ’
Si on a sélectionné le nombre de licences à définir alors les champs ‘ Nombre max de licences
’ et ‘ Prix unitaire ’ apparaitront pour les remplir après le champ ‘ Prix achat HT ‘ se calcule
automatiquement à partir de les champs mentionnés ci-dessus.
Aussi on peut joindre un fichier avec le logiciel par exemple une image ou un fichier texte et le
voir à l’aide du bouton voir (l’œil).
4.5. Cas d’utilisation ‘ gestion des groupes d’utilisateurs ’
Ce cas d’utilisation permet de faire la gestion totale des groupes d’utilisateurs. Dans ce scénario
on va créer un groupe modifier les droits de ce groupe .Ci-après l’ensemble des informations
sur ce cas d’utilisation :
 Acteurs : L’acteur pouvant faire la gestion des groupes d’utilisateurs est le superviseur
 Enchaînement :
 L’authentification autant qu’un superviseur (vérification du nom d’utilisateur et
mot de passe).

 L’accès au menu de présentation de l’application et choisir ‘ configurer le
groupeware ‘
 L’affichage de la fenêtre du groupeware utilisateur
 Clic sur ‘ l’onglet utilisateurs et groupes ‘ puis sur le bouton ‘ nouveau’ pour la
partie des groupes
 Saisir le nom du groupe et valider
 le message d’affirmation de l’ajout du groupe apparaîtra
 clic sur l’onglet gestion des droit et choisir le groupe créé précédemment
 faire modification des droits souhaités et un message indiquant que la modification
a réussi apparaitra
 Action de fin : quitter la fenêtre du groupeware utilisateur
Le diagramme ci-après (Figure 16) illustre le processus de l’ajout d’un groupe et modifier ses
droits.
4.5.3. Fenêtre de la gestion des droits
La figure ci-après (Figure 17) propose la fenêtre d’interface IHM pour la modification des droits
d’un groupe nommé ‘ Fonctionnaires ‘ quoi concerne les fonctionnaires du parc.
Figure 16 : Diagramme de séquence du processus de la création d’un groupe et la modification de
ses droits

Figure 17 : fenêtre du cas d’utilisation ‘ gestion des groupes d’utilisateurs ’
Il s’agit ici la gestion des droits pour la fenêtre principale de l’application, comme on a déjà
discuté dans ce rapport, le fonctionnaire peut voir la liste des matériels et aussi voir les matériels
acheté dans une période ce qui est indiqué dans la figue ci-dessus, donc le superviseur a mis les
autres menus comme : Sites, Utilisateurs, Machines … grisés.
4.6. Cas d’utilisation ‘ gestion des connexions d’un utilisateur ’
Ce cas d’utilisation permet d’afficher les statistiques des connexions d’un utilisateur, dans ce
cas d’utilisation on va visualiser les statistique d’un utilisateur selon une période sélectionner
afin de filtrer les résultats, .Ci-après l’ensemble des informations sur ce cas d’utilisation :
 Acteurs : Les acteurs pouvant visualisés les connexions d’un utilisateur sont : le
responsable et le superviseur
 Enchaînement :
 L’accès au menu de présentation de l’application et choisir ‘ configurer le
groupeware ‘
 L’affichage de la fenêtre du groupeware utilisateur

 Clic sur l’onglet ‘ Statistiques‘
 Saisir le nom de l’application et aussi de l’utilisateur
 Sélectionner une période prédéfinie ou saisir la date de début et la date de fin
 clic sur le bouton ‘ appliquer le filtre ’
 remplissage automatique de la table des connexions
 Action de fin : quitter la fenêtre du groupeware utilisateur
Le diagramme ci-après (Figure 18) illustre le processus de la visualisation de l‘historique des
connexions d’un utilisateur.
Figure 18 : Diagramme de séquence du processus de la visualisation l’historique des
connexions d’un utilisateur
4.5.3. Fenêtre de la visualisation des connexions d’un utilisateur
La figure ci-après (Figure 19) propose la fenêtre d’interface IHM pour la l’affichage l’historique
des connexions concernant un utilisateur.

Figure 19 : fenêtre du cas d’utilisation ‘ gestion des connexions des utilisateurs ’
Après le saisie le nom du l’application, le login concernant un utilisateur spécifique et aussi la
date de début et la date de fin et en cliquant sur appliquer le filtre on voit clairement les résultats
sur la table de l’historique des connexions pour cet utilisateur on peut aussi autant qu’un
superviseur d’effacer cet historique à l’aide du bouton ‘ Effacer l’historique ’
Conclusion
Ce chapitre a donné une première vision sur les fonctionnalités de l’application de la gestion
du parc informatique. Dans ce chapitre, j’ai choisi de décrire 6 cas d’utilisation primaires
dans l’application.
Le chapitre suivant donnera la vision conceptuelle de l’application.

32 Chapitre 3 : Conception
Chapitre 3 : Conception
Ce chapitre définit les éléments résultant de l’analyse des spécifications de l’application de la
Gestion de parc informatique. Les contraintes et les choix de conception seront présentés dans
ce chapitre.
1. Stratégie de développement
L’application à développer sera sous forme d’une application et un petit portail web qui sert à
faire la communication entre l’application et le serveur d’application, Un portail traite les
requêtes d'une tâche ou d'un service donné et génère dynamiquement le contenu web affiché à
l’utilisateur, aussi l’application permet de faire la configuration complète du parc informatique
on se basant sur le serveur qui va faire les traitements qui concerne le parc , aussi elle va me
permettre de me fournir toutes sortes de services généralistes ou spécialisés ( interface de
consultation des informations sur la société, panneau d'information, La gestion des licences, la
gestion des contrats fournisseurs, …)
De point de vue de l’interface de l’application j’ai préféré de travailler avec des fenêtres
modales qui sont , dans une interface graphique, des fenêtres qui prennent le contrôle total du
clavier et de l'écran. Elles sont en général associées à une question à laquelle il est impératif
que l'utilisateur réponde avant de poursuivre, ou de modifier quoi que ce soit, c.à.d. pour
l'application : seule cette application est bloquée jusqu'à la réponse ou l’attente de la valeur de
retour de cette fenêtre ;
Et finalement l’application utilise un seul gabarit (style de l’interface) pour toutes ses
composantes (fenêtres, boutons, Listes déroulantes,…) afin d’être ergonomique et facile à
utiliser.
2. Architecture technique de l’application
Le schéma ci-après (Figure 20) montre l’architecture technique générale et le contexte de
déploiement de l’application.

- Le serveur Manta est composé :
 du service Manta Manager permet de communiquer avec l'application "Centre de
Contrôle HFSQL" (outil d'administration à distance) et d'arrêter et/ou de lancer le ou les
serveurs.
 du service Manta.
Le service Manta est l'application (en mode service) qui traite les demandes et les connexions"
client/serveur " des applications connectées au serveur.
Par défaut, un seul service Manta est présent sur le poste serveur. Cependant, il est possible
d'avoir plusieurs services Manta sur le même poste serveur. Cette configuration permet par
exemple d'associer mon application à un service Manta. Ainsi, si mon application surcharge le
service Manta, seules les applications associées à ce service seront bloquées ou ralenties.
Pour utiliser cette configuration, il est nécessaire que chaque service Manta utilise un port
réseau et un chemin de répertoire de bases de données différents.
Remarque : En cas de défaillance, le service est automatiquement redémarré.
Aussi le serveur HyperFileSQL contient toute la base de données de l’application de la gestion
du parc informatique.
Figure 20 : schéma de l’architecture technique de l’application du parc

3. Comportement dynamique de l’application
Cette partie présente les activités (diagrammes d’activités) majeures du système de l’application
de la gestion du parc informatique.
3.1. Gestion des logiciels
Le processus de la gestion des logiciels commence tout d’abord par l’identification et la
vérification du système des droits d’accès pour l’utilisateur connecté, ensuite cet utilisateur va
accéder à l’interface principale pour aller vers le menu logiciel et après choisir liste des logiciels
pour faire le traitement souhaité qui va être géré par le système.
Le diagramme d’activités ci-après (Figure 21) présente le processus de gestion des logiciels du
parc informatique.
Figure 21 : diagramme d’activité ‘ Gestion des logiciels ’
3.2. Gérer les utilisateurs
Pour gérer les utilisateurs avec leurs droits d’accès, il faut tout d’abord s’authentifier autant
qu’un superviseur, puis l’accès à la fenêtre de la présentation du l’application puis aller à la
configuration du groupeware et ensuite accéder à la création d’un nouveau utilisateur en
remplissant le nom et prénom, le login, le mot de passe, la confirmation du mot de passe et le

téléphone et indiquer si l’utilisateur est un superviseur ou non , finalement on peut soit de
valider et quitter le formulaire ou de valider et de créer un nouvel utilisateur .
Le diagramme d’activités ci-après (Figure 22) présente le processus de gestion des utilisateurs.
Figure 22 : diagramme d’activité ‘ Gérer les utilisateurs ’
3.3. Gérer les droits d’accès
Concernant les droits le superviseur accède à l’onglet du l’application gestion des droits et
sélectionner un utilisateur et puis modifier les droits d’accès puis enregistrer les modifications.
Le diagramme d’activités suivant (Figure 23) présente la gestion des droits pour un utilisateur
ou un groupe choisi.

Figure 23 : diagramme d’activité ‘ Gérer les droits d’accès ’
3.4. Attribuer un utilisateur à une machine
Cette activité sert à lier un utilisateur à un poste de travail de la société, pour effectuer cette
activité il faut accéder à la fenêtre des machines puis sélectionner une machine pour la modifier,
ensuite sur la zone des utilisateurs on clique sur l’icône de l’utilisateur puis la liste des
utilisateurs disponibles apparaitra , finalement on sélectionne un utilisateur concerné et on
valide le choix.
Le diagramme d’activités suivant (Figure 24) présente l’attribution d’un utilisateur à une
machine.

Figure 24 : diagramme d’activité ‘Attribuer un utilisateur à une machine ’
3.5. Rechercher un matériel
La recherche d’un matériel est une activité très importante lorsque qu’il existe des milliers des
matériels dans un parc, il s’agit d’accéder au menu matériel et cliquer sur recherche puis saisir
les informations concerné dans les champs spécifiés par exemple la marque , modèle , durée de
garantie …, finalement la table des matériels se remplie automatiquement s’il existe des
résultats sinon un message apparait dit que aucun résultat trouvé après ça soit rechercher à
nouveau ou quitter la fenêtre de recherche.
Le diagramme d’activités suivant (Figure 25) présente la recherche d’un matériel du parc
informatique.

Figure 25 : diagramme d’activité ‘Rechercher un matériel ’
4. Description de la base de données
4.1. Le modèle logique des données du l’application (MLD)
A partir de l’analyse que j’ai déjà faite lors de la partie analyse du projet, j’ai dégagé un
ensemble d’entités et de dépendances, cela a été traduit par ce modèle de conception de la base
de données qui modélise le système réel étudié.
L’application de gestion de base de données a besoin d’une base de données robuste qui va
contenir un nombre très importants de données ce qui donne une interaction de données et de
l’application souple et sans difficulté c’est pourquoi j’ai choisi la méthode d’analyse merise.
Le diagramme MLD suivant (Figure 26) présente le schéma général de la base de données
réalisé.

Figure 26 : Le modèle logique des données du l’application

4.2. Description des tables
Dans cette partie je vais expliquer les plus importantes tables puisque le schéma contient plus
de 30 tables.
Le champ Rédacteur nous permet de savoir qui est l’utilisateur qui a ajouté un enregistrement
dans une table.
4.2.1. La table ‘ Société ’
Figure 27 : la table ‘ Société ’
Cette table représente la société qui sert à enregistrer les données qui lui concernent le nom,
l’adresse, code postal, la ville …
L’acteur qui remplit cette table à l’aide de l’application est le superviseur
4.2.2. La table ‘ Département ’
Figure 28 : la table ‘ Département ’
Le MLD qu’on a déjà vu chaque société à au moins un département par exemple département
vente, marketing, comptabilité…

4.2.3. La table ‘ Service ’
On voit ici la clé ‘ IDDepartement ’ existe dans cette table ce qui signifie la relation directe
entre elle et la table département c.à.d. chaque département à des services.
Par exemple on peut trouver dans le département marketing le service publicité…
4.2.4. La table ‘ Utilisateur ’
L’une des plus importantes table de cette application, un utilisateur peut s’exister dans un seul
service qui un département de la société.
Cette table contient le nom d’utilisateur, prénom, téléphone, securid est un numéro privé de
l’utilisateur, login et mot de passe, commentaire pour additionner des informations
supplémentaires sur l’utilisateur, fichier lié par exemple il peut être un document ou une image
de l’utilisateur.
Figure 29 : la table ‘ Service ’
Figure 30 : la table ‘ Utilisateur ’

4.2.5. La table ‘ Matériel ’
Cette table contient les informations détaillées sur un matériel, on trouve tous ce qui concerne
la location, la commande, date d’acquisition et d’achat, prix d’achat en cas ou le matériel est
acheté, durée de garantie …
Aussi on trouve que cette table est reliée avec les tables suivantes : modèle, type par exemple
un ordinateur ou imprimante …, fournisseur, machine (poste de travail), contrat et type de
garantie.
Figure 31 : la table ‘ Matériel ’

4.2.6. La table ‘ Machine ’
Une machine comme on a déjà dit est un poste de travail du parc informatique, on trouve des
champs sur cette table comme : le nom, description, Affecté ou non, prête ou non, la date
d’affectation…
La table est en relation avec la table utilisateur puisqu’une machine peut contenir un ou
plusieurs utilisateurs.
4.2.7. La table ‘ Accessoire ’
Cette table concerne les accessoires des machines, les informations qui concerne un accessoire
sont : le nom, référence, type, modèle, prix unitaire, quantité, la facturation et la commande…
On peut trouver comme accessoires : souris, claviers, câbles, hubs ….
Figure 32 : la table ‘ Machine ’
Figure 33 : la table ‘ Accessoire ’

La table est relié directement avec la table marque et fournisseur.
4.2.8. La table ‘ Fournisseur ’
Là on trouve des fournisseurs du parc informatique soit des autres sociétés ou des personnes.
Cette table contient les champs comme il est indiqué sur la figure ci-dessous.
4.2.9. La table ‘ Logiciel ’
Les logiciels sont aussi importants que les matériels, c’est l’esprit vivant de la société, cette
table contient les logiciels avec leur noms, numéros de série, licences, prix d’achat unitaire et
total …
La table est en relation avec la table fournisseur et la table éditeur.
Figure 34 : la table ‘ Fournisseur ’
Figure 35 : la table ‘ Logiciel ’

4.2.10. La table ‘ Loueur ’
Le loueur est la personne qui prend un matériel pour une période bien définie, il a comme
caractéristiques : nom, adresse, code postale, contact, email ….
4.2.11. La table ‘ Contrat ’
Chaque opération de location d’un matériel nécessite un contrat entre le locateur et la société
donc c’est le rôle de cette table qui contient comme champs : date de début de location,
commande de loueur, les frais, cotisation par mois, la durée de location …
Cette table est reliée avec la table loueur et la table société.
Figure 36 : la table ‘ Loueur ’
Figure 37 : la table ‘ Contrat ’

4.2.12. La table ‘ Paramètre ’
Cette table contient les paramètres de l’application concernant les alertes, on trouve par exemple
si la durée de contrat a dépassé le paramètre ‘ échéance contrat ’ une alerte s’affiche lors du
lancement du l’application, la même chose s’applique aux autres paramètres.
4.2.13. La table ‘ Réparateur ’
Les réparateurs sont des personnes qui faire des réparations au matériels du parc il peut s’agit
des ordinateurs, imprimantes, routeurs …
Figure 38 : la table ‘ paramètre ’
Figure 39 : la table ‘ Réparateur ’

4.2.14. La table ‘ Demande intervention ’
Cette table est très importante, La gestion des interventions permet de suivre les incidents gérer
en interne et/ou donnant lieu à une réparation, un retour en garantie.
La création d'une intervention nécessite un code, un numéro de série, une date de demande et
un objet.
La clôture d'une intervention se fait en renseignant la date de fin d'intervention.
Cette table est en relation avec les tables : matériel, machine, utilisateur (intervenant), service,
département et finalement la société.
Conclusion
Ce chapitre a donnée l’aspect conceptuel de l’application de la Gestion du parc informatique,
où j’ai détaillé l’aspect workflow du composant du parc, quel que soit matériel, logiciels,
utilisateurs …
Le chapitre suivant fera l’objet d’une étude technique qui justifiera le choix des technologies
pour la réalisation de l’application.
Figure 40 : la table ‘ Demande intervention ’

48 Chapitre 4 : Etude technique du projet
Chapitre 4 : Etude technique du projet
Ce chapitre met la lumière sur la plateforme utilisée et les outils de développement adoptés
avec la justification de chaque utilisation d’un outil afin de mettre en œuvre l’application de
gestion du parc informatique.
1. L’environnement WinDev
1.1 Présentation WinDev
WinDev 18 permet de gérer, étape par étape, de la conception à la finalisation, le cycle complet
du développement d’une application.
WinDev permet de réaliser toutes les applications dont vous rêvez.
L’environnement WinDev se présente de la manière suivante (figure 41 ci-dessous) :
Figure 41 : Environnement WinDev
WinDev 18 permet de créer des applications qui gèrent des données. Les applications WinDev
accèdent à toutes les bases données, relationnelles ou non du marché. Toutes les bases de
données sont supportées. WinDev 18 est livré en standard avec :

• Hyper File Classic, une puissante base de données relationnelle, déjà utilisée sur des
millions de sites.
• Hyper File Client/ Serveur, une puissante base données relationnelle Client/ Serveur.
WinDev 18 propose certainement l’environnement de travail le plus puissant, le plus facile et
le plus intégré du marché ! Les Développeurs Créeront facilement des superbes applications.
L’éditeur de fenêtres de WinDev 18 est 100% WYSIWYG (« ce que vous voyez est ce que
vous aurez »). Il permet de réaliser facilement de superbes fenêtres reliées aux données.
1.2 Argumentaires généraliste WINDEV
Logiciel commercialisé pour la première fois en 1993, il dispose d’une expérience hors du
commun.
WINDEV a évolué sans cesse depuis sa création, a innové et innove sans relâche pour le plus
grand bénéfice de ses utilisateurs.
Précurseur dans le domaine du « Framework » (mis en place dès 1993), de l’intégration totale
des outils nécessaires à la gestion du cycle de vie des applications, du déploiement libre et
gratuit, et chantre de l’ouverture totale à toutes les technologies. Numéro un incontesté en
France depuis des années, il n’est pas près de laisser sa place à quiconque, principalement en
raison de son évolution permanente dans le respect des besoins réels des équipes de
développement.
Aujourd’hui en version 19, WINDEV, comme son célèbre slogan l’affirme, permet de
développement réellement « 10 fois plus vite », pour le plus grand bénéfice des développeurs
et des utilisateurs.
1.3 Que fait-on avec WinDev
WinDev est un AGL (Atelier de Génie Logiciel). Il vous permet de développer des applications
dans tous les domaines :
 Gestion (Comptabilité, Paie, Finances, Commerce, Stock, ERP, CRM, EAI,
EDI, VPC, GRM, …) ;
 Industrie (Robots, Caisses, Automates, Balances, Lecteur de badge, Supervision, …) ;
 Médical ;
 Multimédia ;
 Internet ;
 Accès Distant...

WinDev est un outil de développement complet qui intègre tous les outils nécessaires au cycle
de réalisation d’une application.
Contrairement à d’autres langages de développement traditionnels, il n’est pas de chercher et
de rajouter des modules pour concevoir, tester et installer une application.
Le L5G (Langage de 5éme Génération) de WinDev, le WLangage, vous étonnera par sa
simplicité : quelques heures suffisent pour appréhender le langage, une semaine suffit en
général pour maitriser toute sa puissance.
Comme il est en français, le WLangage (disponible également en anglais) vous fera gagner du
temps.
1.4 L’argumentaire technique
Les technologies innovantes mises en œuvre par WINDEV profitent de la maturité de celui-ci.
La réalité du terrain est souvent éloignée des théories des instituts d’analyse et de prospective…
Les besoins de performance des utilisateurs sont une réalité qui ne permet aucuns errements.
Une entreprise n’est en général pas un laboratoire de recherche et doit utiliser des logiciels
robustes, rapides et qui répondent aux besoins réels des utilisateurs.
WINDEV s’appuie sur des technologies éprouvées, aux performances et à la sécurité qui
permettent une utilisation réelle.
Les équipes de PC Soft travaillent en permanence surtouts les technologies émergentes, mais
n’implémentent pas celles qui sont manifestement immatures ou dangereuses ou vouées
indubitablement à l’échec.
WINDEV et WEBDEV évoluent en permanence.
Il est important que les solutions mises en œuvre soient pérennes : c’est le cas avec WINDEV,
depuis sa version 1.
WINDEV évolue souvent (en assurant la compatibilité avec l’existant).
1.5 Argumentaire Base de Données
WINDEV est ouvert à toutes les bases de données du marché : Oracle, SQL Server, MySQL,
AS/400, Sybase, Informix, DB2, Access, dbase, etc…; il est également livré avec la puissante
base de données HyperFileSQL.
L’accès aux bases de données s’effectue par ODBC, OLE DB ou nativement (A savoir : certains
accès natif doivent être acquis séparément).

A la différence des autres environnements, la structure des bases de données est connue de
l’environnement : cela permet d’automatiser et sécuriser les phases du développement et de
maintenance.
1.6 Argumentaire réactivité et vitesse de développement
C’est un lieu commun de dire que le monde bouge vite.
Les lois évoluent sans cesse, la concurrence est acharnée dans de nombreux secteurs, les besoins
sont souvent urgents.
Les applications informatiques doivent se conformer à ces évolutions. Il est donc nécessaire de
pouvoir créer et modifier vite des applications.
C’est là un avantage qui est le fondement même de WNDEV : sa vitesse de développement, ses
capacités de modification automatique, sa gestion intégrée de la base déployée (live-update en
particulier) permettent aux équipes une réactivité inconnue sans lui.
Seul WINDEV permet un développement robuste aussi rapide. Des projets qui demanderaient
plusieurs mois avec d’autres outils sont souvent réalisés en quelques jours avec WINDEV.
2. Architecture et outils
2.1 Architecture logicielle du système
Une architecture logicielle est un schéma d'organisation structurel fondamental pour les
systèmes logiciels. Elle fournit un jeu de sous-systèmes prédéfinis, spécifie leurs
responsabilités, et inclut les rôles et les instructions générales pour organiser les relations entre
eux. Sans une bonne architecture, un système d'information est difficile à comprendre, prédire,
gérer et optimiser. Les buts d'une architecture sont :
- La compréhension du système étudié, en définissant ses limites.
- La gestion de la croissance du système.
La future architecture du système doit satisfaire un certain nombre d’exigences telles que la
sécurité, la disponibilité et la maintenance.
Parmi les différentes façons de structurer une architecture, la mieux comprise et maîtrisée en
informatique est l'approche par couches. Une couche est une division logique, horizontale d'un
système qui fournit une abstraction particulière du système aux couches supérieures.
Chaque couche possède des responsabilités spécifiques. Dans une structuration par couches, les
couches inférieures prennent en charge des responsabilités qui offrent un socle de base pour les

couches supérieures, permettant d'abstraire celles-ci des problématiques qui ne les concernent
pas.
Aujourd'hui, les logiciels « Change On Demand» sont devenus très populaires, les besoins
changent vite et il faut s'adapter le plus rapidement possible. De nombreux producteurs de
logiciels, proposent dorénavant une solution évolutive. Une des approches pour réaliser ce
genre de produit est une Architecture Orientée Services.
Celle-ci est devenue très répandue avec l'explosion des Services Web.
Cette approche consiste à diviser le logiciel répondant à un problème, en un ensemble d'entités
proposant des services. Chacune de ces entités peut utiliser les services proposés par d'autres
entités. Nous obtenons ainsi un réseau de services interagissant entre eux. Cette architecture
s'appuie sur une architecture à composants.
J’ai découpé mon application logicielle en cinq couches logiques. Cette architecture permet de
créer de manière incrémentale de nouvelles fonctions, de les combiner aux services existants
pour créer des applications composites tout en garantissant un bon niveau de maintenance et de
flexibilité et elle répond ainsi aux caractéristiques tracées pour notre outil.
D'où le schéma récapitulatif suivant :
Figure 42 : Architecture logicielle
• Couche Présentation :
Cette couche est faite principalement pour gérer le domaine visuel de l’application et pour gérer
les interactions avec les utilisateurs. Chargée de dessiner les fenêtres et autres composants
graphiques, elle intercepte les événements et appelle la couche Service, après la vérification des
autorisations auprès d’un service de sécurité.
• Couche services :

C’est l’intermédiaire entre la couche métier et la couche présentation, cette couche expose
différentes entités proposant les services offerts par la couche métier, en effet, la couche
présentation ne manipule plus directement les objets métier de la couche métier mais passe par
des services. De cette manière, les fonctionnalités sont restreintes et la réduction des échanges
entre les couches est assurée.
• Couche métier :
Cette couche est concentrée sur le métier de l’application, c'est-à-dire les règles métier,
sémantiques et logiques. Sa charge principale consiste à garantir la validation sémantique de
l'information métier. Cette couche est basée sur le modèle objet.
• Couche Persistance :
Cette couche est certainement l'une des plus importantes. C'est dans cette couche que je trouve
les fonctionnalités de base qui permettent de créer, rechercher et supprimer des entités métier
dans le respect des propriétés transactionnelles. C'est également dans celle-là que les
mécanismes de conversion objet/relationnel peuvent prendre place.
• Couche Stockage :
Cette couche est responsable du stockage physique de données. Elle assure un support
transactionnel et elle est basée sur un modèle relationnel.
2.2 Choix des langages et outils
2.2.1 Modèle RAD
La méthode de Développement Rapide d'Applications, dite méthode RAD (acronyme de
l'anglais Rapid Application Development), est la première méthode de développement de
logiciels où le cycle de développement est en rupture fondamentale par rapport à celui des
méthodes antérieures. Ce nouveau cycle qualifié d'itératif, d'incrémental et d'adaptatif, se
retrouvera ensuite dans toutes les méthodes dites « agiles » publiées par la suite.
 Aperçu :
La méthode RAD, après deux courtes phases de formalisation structurée de l'expression des
besoins (CADRAGE) et de définition globale de l'architecture technique (DESIGN), inclut dans
sa phase principale(CONSTRUCTION) la réalisation, la validation immédiate et les tests d'une
application en mode itératif-incrémental-adaptatif. L'objectif de la méthode, qui implique
activement l'utilisateur final dans un principe de "validation permanente", est d'obtenir un
applicatif en adéquation avec les réels besoins.

Figure 43 : Avantages de Méthode RAD.
 Développement :
James Martina développé la méthode RAD à la fin des années 1980, à IBM, en se basant sur
les publications de Barry Boehm (modèle en spirale), Tom Gilb (cycle de vie évolutif), Scott
Shultz (production en itérations rapides) ainsi que Brian Gallagheret Alex Balchin. Il l'a
formalisée en la publiant en 1991.
Des compléments et des actualisations sont introduits à partir de 1994, notamment par Jean-
Pierre Vickoff pour l'aspect francophone (processus RAD2 publié par le Gartner Group) et
Jennifer Stapleton en Grande-Bretagne (processus DSDM).
L’apport de J. Martin avec la méthode RAD fut de formaliser techniquement le premier postulat
« agile », à savoir que pour qu'une prédiction de projet puisse se réaliser à tous les coups, il
fallait que certains aspects du pilotage soient d’autres soient variables. Il proposa des techniques
de priorisation pour gérer les deux principales variantes possibles de ces situations (délais fixe
ou budget fixe). Les notions additionnelles de visibilité, de risque et de fiabilité (ou de qualité)
comme variables de planification stratégique d’un projet furent introduites plus tard.
 Structure de la méthode :
La méthode RAD implique :
 Un cycle de développement sécurisant et court fondé sur un phasage simple : Cadrage,
Design, Construction et l’absolu respect d’une dimension temporelle (90 jours
optimum, 120 jours maximum) [Martin 1991].
 Une architecture de communication engageant des groupes de travail de structure et de
composition variable selon les besoins des phases et respectant un mode opératoire
précis structuré en trois étapes : précession, post post-session [Mucchielli 1987].

 Des méthodes, techniques et outils permettant de définir et d’appliquer des choix
portant sur quatre natures d'objectifs potentiellement contradictoires : budget, délais,
qualité technique, qualité fonctionnelle et visibilité [Vickoff 1998].
 Une architecture de conception s’appuyant sur les techniques de l'objet et
particulièrement sur celles qui permettent une conception «en vue de modifications»
[McCarty 1997].
 Une architecture de réalisation qui impose, pour garantir la qualité technique, des
normes minimales, des revues de projet, des jalons zéro défaut et qui recommande,
pour garantir la qualité fonctionnelle, le prototypage actif et les focus de visibilité
[McConnell 1996].
Figure 44 : Evolution d’un projet avec la méthode RAD
La méthode RAD structure le cycle de vie du projet en 5 phases (dont 3 systématiques) :
1. L’initialisation prépare communication.
2. Le CADRAGE définit un espace d’objectifs, de solutions et de moyens.
3. Le DESIGN modélise la solution et valide sa cohérence systémique.
4. La CONSTRUCTION réalise en prototypage
5. La finalisation est réduite à un contrôle final de qualité en site pilote.

Figure 45 : Parallélisassions et sérialisation des phases de projet avec la méthode RAD.
 Initialisation :
Préparation de l’organisation et communication.
Cette phase permet de définir le périmètre général du projet, de structurer le travail par thèmes,
de sélectionner les acteurs pertinents et d’amorcer une dynamique de projet. Cette phase
représente environ 6% du projet en charge.
 Cadrage :
Analyse et expression des exigences.
La spécification des exigences est du ressort des utilisateurs. Ils expriment leurs besoins lors
d’entretiens de groupe.
Il est généralement prévu de 2 à 5 jours de sessions par commission (thème). Cette phase
représente environ 9% du projet.
 Design :
Conception et modélisation.
Les utilisateurs sont également impliqués dans cette étape. Ils participent à l’affinage et à la
validation des modèles organisationnels : flux, traitements, données. Ils valident également le
premier niveau de prototype présentant l’ergonomie et la cinématique générale de l’application.
Il est prévu entre 4 et 8 jours de sessions par commission.
Cette phase représente environ 23% du projet. A partir de la phase de Design la parallélisassions
du travail est possible
 Construction :
Réalisation, prototypage.

Durant cette phase, l’équipe RAD (SWAT) doit construire l’application module par module.
L’utilisateur participe toujours activement aux spécifications détaillées et à la validation des
prototypes. Plusieurs sessions itératives sont nécessaires. Cette phase représente environ 50%
du projet. A partir de la phase de Construction, à la parallélisassions du travail peut s’ajouter la
sérialisation.
 Finalisation :
Recette et déploiement.
Des recettes partielles ayant été obtenues à l’étape précédente, il s’agit dans cette phase
d’officialiser une livraison globale et de transférer le système en exploitation et maintenance.
Cette phase représente environ 12% du projet.
 Outils RAD :
La méthode, sans être liée aux outils, recommande l'utilisation d'outils de programmation à
interface graphique (CASE), qui permet d'obtenir rapidement des prototypes. A ce sujet, il ne
faut pas confondre la méthode RAD (d'où sont issues les approches Agiles actuelles) qui
recherche la qualité applicative fonctionnelle et technique avec les outils RAD, dont la
production automatique de code est souvent qualifiée de "sale".
• Powerbuilder
• uniPaaS (anciennement connu sous le nom de Magic eDeveloper) est une plateforme
RAD qui accélère le développement d'applications Métier en associant un paradigme de
développement unique de bout en bout à un moteur de règles fondé sur les métadonnées.
Le développement est accéléré de par le fait que le code est précompilé dans le système.
• Delphi (Lazarus ou ainsi que le Visual Basic) est un outil RAD en ce sens qu'il permet
assez facilement de créer des programmes à l'aide d'une interface graphique dotée de
nombreux outils et de modules prêts à l'emploi.
• WinDev (ainsi que WebDev) est un outil RAD plus avancé car il permet à partir d'une
analyse Merise ou UML de produire un applicatif final et opérationnel.
WinDev Mobile permet lui de créer rapidement des applications pour les matériels
mobiles.
• Authorware crée lui-aussi un applicatif final en dessinant un diagramme à l'aide
d'icônes.
• JBuilder
• C++ Builder
• C# Builder
• Leonardi est un outil RAD adapté au développement des IHM.

• Limbas est un outil RAD 100% web (développement et application cible) sous licence
GNU GPL 2 incluant notamment des fonctionnalités GED et Groupware.
2.2.2 WLangage
Le WLangage est un langage de programmation de 5éme génération inclus dans les outils de
développement WinDev, WebDev et WinDev Mobile. Il est propriétaire et ne peut être
manipulé qu'avec les outils PC SOFT. Le WLangage est né en 1992 avec la première version
de WinDev.
Même s'il y a explicitement une première phase précoce de compilation, le byte code WLangage
est exécuté par une machine virtuelle ou converti en code natif lors de l'exécution par un
compilateur à la volée (Just in time, JIT). Le Framework est disponible sous Windows (32 bits,
64 bits et CE) et partiellement sous Linux (sans interface graphique).
Le WLangage peut également s'appuyer sur le Framework Java pour une partie de ses
fonctionnalités, ce qui permet une indépendance relative et limitée du fichier exécutable par
rapport au système d'exploitation cible. Il en va de même dans WebDev, où le WLangage peut
s'appuyer sur le Framework PHP, sans toutefois permettre d'utiliser toutes les possibilités de ce
dernier.
Initialement prévu pour Windows, une partie des fonctions du WLangage est basée sur l'API
Microsoft Windows.
Le WLangage est un langage de programmation procédurale qui permet la programmation
impérative et la programmation orientée objet. C'est en fait un langage de programmation multi-
paradigme.
Le WLangage contient des fonctions de haut niveau, telle que la fonction EcranVersFichier,
qui effectue les affectations du contenu des champs d'une fenêtre vers des tables stockées dans
un fichier ou des variables, auxquelles les champs ont été préalablement reliés (databinding).
Le WLangage autorise une utilisation souple du typage. Les variables doivent être typées mais
les paramètres formels des procédures ou les itérateurs de boucles peuvent ne pas l'être. Il est
ainsi possible dans un même projet de combiner des procédures avec typage strict pour profiter
de la rigueur du typage statique et des procédures sans typage pour profiter de la souplesse du
typage dynamique et du duck typing.
2.3 Système de gestion de la base de données relationnelle
HyperFileSQL est un système de gestion de base de données relationnel exploité par les
logiciels WinDev, WebDev et WinDev Mobile.

Le système de gestion de base de données relationnelle HyperFileSQL nous permet de gérer
ces données en toutes sécurités. Les performances sont remarquables.
Utilisé sur plusieurs millions de postes à travers le monde, la flexibilité et l’évolutivité de
HyperFileSQL permettent de répondre aux besoins les plus exigeants des applications à mission
critique en temps réel.
2.3.1 Généralités :
HyperFileSQL est un puissant SGBDR (Système de Gestion de Base de Données
Relationnelle).
HyperFileSQL est décliné en trois versions :
• Version mobile (embarquée) ;
• Version locale (monoposte ou réseau) ;
• Version Client/ Serveur (et cluster).
HyperFileSQL est adapté à tous les types d’applications : applications métiers, applications
critiques temps réel, progiciels, serveurs d’applications, serveurs Web, PC stand-alone ou
périphériques mobiles.
2.3.2 Performance, Sécurité, Ouverture, Flexibilité :
HyperFileSQL est le choix idéal comme moteur de bases de données.
• Ouverture : basé sur les standards de l’industrie, HyperFileSQL ne vous enferme pas
dans une technologie propriétaire.
• Flexibilité : le support des volumes de données importants (plusieurs dizaines de
milliards de lignes dans une table) est assuré.
• Indépendance : vis-à-vis de la plateforme : les tables peuvent être déplacées d’un
Client/ Serveur vers un mobile, d’un serveur Windows vers un serveur linux, etc.…
• Extensibilité : vous passez sans contraintes d’un utilisateur à plusieurs centaines
d’utilisateurs, d’une architecture 2 tiers à une architecture multi-tiers…
• Econome ressources : le moteur client/serveur occupe moins de 20Mo sur disque.
HyperFileSQL fonctionne en environnement hétérogène : Windows, Linux, Mac, TSE,
Citrix, ADSL, VPN, Wi-Fi…
• La compatibilité ascendante et descendante des tables est assurée.
• Pérennité de l’éditeur : PC Soft est présent depuis plus de 25ans, et est n°1 en France
dans le monde des AGL.
• Performance : grâce à une gestion optimisée des index et une gestion affinée des
caches, la vitesse est permanente.

• Sécurité d’accès : la protection contre l’injection SQL est assurée via la création
automatique d’IHM sécurisées.
2.3.3 Coût d’usage (TCO) réduit :
Une caractéristique de HyperFileSQL est son déploiement illimité libre et gratuit.
Il n’y a aucun coût facturé, ni en fonction du nombre de processeur du serveur, ni en fonction
du nombre de postes client, ni annuellement, ni en fonction du type d’application…
HyperFileSQL est livré en une édition systématiquement complète, avec toutes les
fonctionnalités, gratuite. Les coûts de maintenance sont très réduits.
Figure 46 : HyperFileSQL

Conclusion
Ce chapitre avait comme but de présenter l’ensemble de mes recherches au niveau des
technologies et de l’environnement dans lequel s’inscrit mon projet, aussi j’ai introduit les
outils et les langages que j’ai utilisés pour la réalisation de mon application le chapitre suivant
présente la réalisation et la mise en marche de l’application

62 Chapitre 5 : mise en œuvre du projet
Chapitre 5 : mise en œuvre du projet
Cette partie a pour but la description de la phase de mise en œuvre de la solution. Je présente
d’abord l’architecture applicative du système et je détaille ensuite la réalisation de
l’application.
1. Présentation
Afin de gérer et contrôler la gestion de parc informatique, les opérateurs utilisent des fichiers
Excel pour l’accumulation des données techniques afin d’élaborer un fiche des résultats
journaliers de parc concernant l’achat des matériels, renouvellement des licences des antivirus
…
Il existe plusieurs types de matériels et logiciels, Cependant la quantité des données techniques
à gérer quotidiennement est immense, les données totalisant en moyenne 80 à 100 par poste de
travail, donc on peut se trouver avec un flux dépassant les 400 données journalières. Ces
informations demeurent non classées et mal organisées, on aura des difficultés pour accéder
aux données récentes cause le manque d’organisation, quantité immense des données, la non
disponibilité des fichiers sur le serveur de la société...
Il est donc indispensable pour la direction de s’appuyer sur une démarche d’organisation de la
gestion des biens technologiques et des moyens humains afin de diminuer et de rationaliser les
coûts de la gestion et le suivi de parc.
Donc le but de mon projet est la conception et la réalisation d’une solution permettant une
meilleure gestion et un suivi quotidien de l’évolution du parc.
Cette solution sera composée principalement de six modules :
 Gestion des utilisateurs
 Gestion des machines
 Gestions des matériels
 Gestions des logiciels
 Gestions des incidents
 Gestions des interventions

2. Réalisation de la solution
Le système développé suit l’architecture applicative déjà présentée dans le chapitre IV. Il
comporte les différentes couches applicatives du système :
• Couche Présentation.
• Couche Services.
• Couche Métier.
• Couche Persistance.
• Couche Données.
2.1 La couche Données :
Cette couche comporte le schéma de la base de données du système. Ce schéma qui le modèle
physique de donnée, a été généré à partir du MCD de l’application.
2.2 La couche Mapping et Persistance :
Cette couche se charge de la persistance des objets métier manipulés par les services. En effet,
cette couche se compose des descripteurs des classes métier et des tables associées à ces classes
dans la base de données.
5.3 La couche Métier :
Cette couche comporte les différents paquetages métier du système. Ces paquetages sont
appelés par les composants de la couche Services pour répondre aux requêtes des utilisateurs.
5.4 La couche Services :
Cette couche fait appel aux paquetages de la couche métier par des composants pour répondre
aux requêtes des utilisateurs.
5.5 La couche Présentation :
Cette couche concerne les interfaces Homme-Machine que j’ai développé en utilisant WinDev
code behind WLangage.
3. Développement :
3.1 Outils de développement :
Planification : Edraw max

Développement : WinDev.
Conception de la base de données : WinDev.
Modélisation (diagrammes) : Edraw max
3.2 Environnement de modélisation Edraw :
Pour réaliser les différents diagrammes du projet j’ai utilisé le logiciel « Edraw Max 7.2 »
Figure 47 : logo du logiciel Edraw MAX
Edraw Max est un utilitaire de création de plans, de schémas et de diagrammes qui couvre un
nombre impressionnant de types de documents.
Citez n'importe quel type de document de type modélisation en 2D, Edraw Max le propose.
Pour le management ? Organigrammes, brainstorming, schémas cognitifs... Pour la
construction ? Circuits électriques, plans d'aménagement en 2D... Pour l'aménagement du
territoire ? Cartes de ville ou de pays, plans de métro... La liste inclut aussi des modélisations
de sites internet et même des dessins de mode (plutôt basiques, mais tout de même).
Malgré l'avalanche de possibilité, l'interface rassure, reprenant l'aspect de Microsoft Office
2007. On est en terrain connu : les objets s'insèrent par un simple glisser/déposer et sont
redimensionnables à volonté.
La base de données des cliparts inclut plus de 2000 objets. Cela correspond à quelques centaines
de dessins pour chaque type de diagramme, ce qui est impressionnant, d'autant plus qu'ils sont
souvent de bonne qualité.
Edraw Max permet de créer un diaporama à partir de plusieurs documents. Pas de format PPT,
réservé à PowerPoint : c'est ici un exécutable au format .EXE qui est exporté. C'est aussi là que
commencent les ennuis : l’EXE en question alerte l'antivirus de l'ordinateur. Impossible de le
faire tester par virustotal.com, qui bizarrement n'arrive pas à l'analyser.

3.3 Environnement de développement WinDev
Figure 48 : Logo du l’atelier génie logiciel WinDev 18
WinDev 18 permet de gérer, étape par étape, de la conception à la finalisation, le cycle complet
du développement d’une application.
WinDev permet de réaliser toutes les applications dont vous rêvez.
WinDev 18 permet de créer des applications qui gèrent des données. Les applications WinDev
accèdent à toutes les bases données, relationnelles ou non du marché. Toutes les bases de
données sont supportées. WinDev 18 est livré en standard avec :
• Hyper File Classic, une puissante base donnée relationnelle, déjà utilisée sur des millions de
sites.
• Hyper File Client/ Serveur, une puissante base données relationnelle Client/ Serveur.
WinDev 18 propose certainement l’environnement de travail le plus puissant, le plus facile et
le plus intégré du marché ! Les Développeurs Créeront facilement des superbes applications.
L’éditeur de fenêtres de WinDev 10 est 100% WYSIWYG (« ce que vous voyez est ce que
vous aurez »). Il permet de réaliser facilement de superbes fenêtres reliées aux données.
4. Présentation de quelques interfaces
Un exemple d’interfaces est représenté par les figures suivantes :

Figure 49 : fenêtre d’authentification
Pour bénéficier des services de mon application chaque utilisateur doit saisir un nom
d’utilisateur et un mot de passe valide. Ce dernier sera redirigé soit pour l’interface des
administrateurs, ou des utilisateurs simples.
Figure 50 : fenêtre compte administrateur
Après l’authentification d’un superviseur est réussie, la fenêtre ‘ comptes d’administrateur ’
ouvre automatiquement.
Le superviseur a le choix de soit d’ouvrir la fenêtre principale soit de configurer le groupeware
utilisateur (gestions des utilisateurs, gestions des droits …) ou de quitter l’application.

 Partie Superviseur
Figure 51 : fenêtre de l’administration des utilisateurs et les groupes
Dans cette fenêtre on fait la gestion des utilisateurs de l’application (ajout, modification,
suppression) ainsi que des groupes lorsqu’on clique sur Nouveau dans la partie ‘ Utilisateurs ’
cette fenêtre s’affiche :

Figure 52 : fenêtre de l’ajout d’un nouvel utilisateur
Après l’affichage de cette fenêtre on doit la remplir par les informations demandées ci-dessous
(login, nom prénom, téléphone), après ça on peut laisser le choix à ce nouvel utilisateur de créer
son mot de passe au premier lancement ou de le mentionner directement.
Aussi lorsqu’on ne mentionne pas le login par exemple, un message d’erreur apparaît
demandant de remplir le champ ‘ login ’.

Figure 53 : fenêtre de la gestion des droits
Le superviseur fait l’appel à cette fenêtre pour bien gérer les droits de chaque utilisateur ou
groupe il commence par choisir un enregistrement puis la liste des éléments de l’application
s’afficheront t il choisit l’élément qui souhaite modifier ses droits d’accès où il y a quatre
types d’états pour les champs d’un élément : Défaut, inactive, Grisé et invisible.
Figure 54 : paramétrage des droits pour la fenêtre ‘ Fiche département ’

Figure 55 : fenêtre des statistiques de connexion de l’application
Cette fenêtre permet au superviseur de voir les différents utilisateurs qui ont connecté à
l’application en précisant la date de début et la date de fin ou choisir une période déjà prédéfinie
comme la semaine en cours, le mois en cours… , elle donne les informations sur le login de cet
utilisateur, son adresse IP, la date de l’accès à l’application et l’heure après l’application du
filtre de la période.
Figure 56 : fenêtre de récupération des données

Le superviseur demande cette fenêtre pour qu’il récupère une liste déjà fait concernant les
utilisateurs et leurs mots de passe ainsi les groupes et la configuration des droits, ces données
peuvent être en n’importe quels formats : Hyperfile SQL, Accès natif MySQL, dBase ….
 Fenêtre principale
Figure 57 : fenêtre principale de l’application
C’est le point d’accès de l’application, juste après l’affichage un message d’alerte s’affiche
indiquant que un la date de garantie d’un matériel prend fin dans 30 jours ou moins (figure ci-
dessous), cette fenêtre d’alerte peut s’afficher plusieurs fois selon les matériels concernés.

Figure 58 : Alerte de l’expiration de la garantie d’un matériel
 Gestion des entreprises
Figure 59 : La liste des entreprises et la fiche de création d’une nouvelle entreprise

 Gestion des utilisateurs
Figure 60 : La liste des utilisateurs (employeurs) et la fiche de création d’un nouvel
employé
Cette fenêtre permet de faire la gestion des employés de la société, chaque utilisateur se
caractérise par le nom, prénom, la société qui travaille avec, le département concerné et aussi
le service qu’il s’en charge …
 Gestion des matériels

Figure 61 : La liste des matériels et la fiche d’ajout d’un nouvel matériel
La fiche de la création d’un nouvel matériel commence par choisir le type : ordinateur,
imprimante, écran…, ensuite choisir la marque et le modèle.
Le type, la marque, le modèle et la machine se créent par des autres fenêtres qui existent dans
l’application, Le sélecteur d’achat ou location permet de visualiser des champs selon le cas
sélectionné, s’il s’agit de la location les champs loueurs et le N° de contrat s’affiche sinon les
champs : date commande, N° commande, date d’achat et le prix achat HT qui s’affichent
Dans le pied de la fenêtre on trouve le fournisseur, la durée de garantie, numéro de facture, et
le type de garantie.

Figure 62 : Rechercher un matériel
Dans cette fenêtre on choisit le type de matériel et aussi la marque afin que l’application nous
donne une liste contient les matériels qui répond au critère de la recherche.
 Gestion des logiciels
Figure 63 : La liste des logiciels et la fiche d’ajout d’un nouvel logiciel
Le même principe que les logiciel sauf qu’ici le logiciel se caractérise par son éditeur et le
nombre de licences : soit de sélectionner illimité en cas d’un logiciel libre, soit de mentionné le
nombre de licences dans ce cas on doit déterminer le nombre de licence et aussi le prix unitaire.
Le champ ‘ Prix achat ’ se remplie automatiquement.

Figure 64 : La liste des machines (poste de travail) et la fiche d’ajout d’une nouvelle
machine
Le superviseur demande cette fenêtre pour gérer les postes de travails du parc, pour ajouter une
nouvelle machine on mentionne : le nom du machine, on lui attribue un utilisateur et en coche
en attente dans le cas que ce poste attend l’activation ou cocher ‘ En prêt ’ s’il est prêt, la date
d’affectation et date pose
Conclusion
Ce chapitre a été consacré à la présentation des outils et technologies manipulés ainsi que la
présentation de l’application Gestion du parc informatique à travers la description de ses
différentes interfaces.
La conclusion de notre rapport fera l’objet de la section suivante.

77 Conclusion et perspectives
Conclusion et perspectives
Ce projet m’a permis de mettre en pratique mon esprit d’étude, d’analyse et de critique. De
mettre en application certaines de nos connaissances et notre savoir acquis lors de la période de
la formation à l’ENSA et de découvrir la différence entre les projets professionnels et ceux à
caractère pédagogique.
Je rappelle que mon projet de fin d’études avait pour objectif la Réalisation et l’Intégration
d’une application de Gestion du parc informatique dans le portail interne d’ADDLOG.
L’analyse des besoins, la conception, la réalisation du système de gestion du parc informatique,
les tests unitaires et les tests d’intégrations ont été les phases du cycle de développement de
notre projet.
Ce stage a été également l’occasion de découvrir le dynamisme et l’enthousiasme qui
caractérise les équipes ADDLOG. Les réunions régulières effectuées avec mon encadrants dans
la société et à l’école m’ont permis de mettre en œuvre les concepts de gestion de projets acquis
à l’ENSA.
Les difficultés majeures que j’ai rencontrées durant ce projet résident essentiellement dans la
nouveauté des technologies WinDev 18 et surtout les nouvelles fonctions qui sont ajoutées par
rapport à la version 17 qui manque une documentation importante.
L’applicatif réalisé répond à la plupart des besoins actuels qui ont été formulé par les différents
intervenants que j’ai rencontrés. Reste à préciser que la conception effectuée et l’architecture
technique adoptée garantiront l’extensibilité du système développé et permettront d’ajouter
d’autres services pour répondre aux futurs besoins éventuels, aussi sans oublier j’ai eu une
occasion d’implanter le système de gestion du parc informatique au sein d’une autre société qui
s’appelle COFICAB , maintenant je fais le stage avec cette société, mais ici le travail demandé
c’était de transformer l’application selon les besoins de COFICAB.
Les perspectives possibles à la suite du présent projet sont multiples et couvrent plusieurs
aspects, tels que rendre l’application en architecture client-serveur, contrôler les postes de
travail à distant et ajouter des fonctionnalités comme les codes-barres imprimés dans les
factures…

Bibliographie
[1] Addlog, Présentation de ADDLOG, Tanger, 27/06/212.
[2] Addlog, Organigramme de ADDLOG, Tanger, 29/05/2012.
[3] M. SAFY et S. Chelbat, Cahier des charges relatif à la Réalisation de l’application
de la Gestion du parc, Tanger, 25/04/2014.
[4] H. BENMOUSSA, Besoins et spécifications du parc informatique, Tétouan,
14/03/2014.
[5] H. BENMOUSSA, Plan d'action du projet : parc informatique, Tétouan,
26/03/2014.
[6] M. Blay-Fornarino, Activity Diagrams, Paris, 29/12/2013.
[7] JB, Pourquoi une méthode 'analyse' ?, 27/07/2007.
[8] D. Longuet, UML : Diagrammes de séquence, Paris-Sud, 22/10/2012.
[9] WinDev Développer 10 fois plus vite, Auto-formation version 18.

Webographie
[10] http://fr.wikipedia.org/wiki/Merise_%28informatique%29
[11] http://www.commentcamarche.net/genie-logiciel/cycle-de-vie.php3
[12] http://fr.wikipedia.org/wiki/Gestion_libre_de_parc_informatique
[13] http://www.reseaucerta.org/docs/cotelabo/coteLaboOCSGLPI_V1.pdf
[14] http://fr.slideshare.net/nazihnemri/final-2-30702429
[15] http://www.pcsoft.fr/ - site officiel du windev
[16] https://www.facebook.com/groups/335517059889202/ - groupe de discussion
sur les problèmes techniques WinDev
[17] http://fr.wikipedia.org/wiki/Cycle_en_V

80 Annexe 1 : Le Design Pattern MVC
Annexe 1 : Le Design Pattern MVC
1. Le design pattern MVC
Le Modèle-Vue-Contrôleur (en abrégé MVC, de l'anglais Model-View-Controller) est une
architecture et une méthode de conception qui organise l'interface Homme-machine d'une
application logicielle. Il divise l'IHM en un modèle (modèle de données), une vue (présentation,
interface utilisateur) et un contrôleur (logique de contrôle, gestion des évènements,
synchronisation), chacun ayant un rôle précis dans l'interface. Cette méthode a été mise au point
en 1979 par Trygve Reenskaug, qui travaillait alors sur Smalltalk dans les laboratoires de
recherche Xerox PARC.
1.1. Architecture MVC
L'organisation globale d'une interface graphique est souvent délicate. L'architecture MVC ne
résout pas tous les problèmes. Elle fournit souvent une première approche qui peut ensuite être
adaptée. Elle offre aussi un cadre pour structurer une application.
Figure 65 : Architecture MVC

Ce modèle d'architecture impose la séparation entre les données, les traitements et la
présentation, ce qui donne trois parties fondamentales dans l'application finale : le modèle, la
vue et le contrôleur.
1.1.1. Le modèle
Le modèle représente le comportement de l'application : traitements des données, interactions
avec la base de données, etc. Il décrit ou contient les données manipulées par l'application. Il
assure la gestion de ces données et garantit leur intégrité. Dans le cas typique d'une base de
données, c'est le modèle qui la contient. Le modèle offre des méthodes pour mettre à jour ces
données (insertion, suppression, changement de valeur). Il offre aussi des méthodes pour
récupérer ces données. Les résultats renvoyés par le modèle sont dénués de toute présentation.
Dans le cas de données importantes, le modèle peut autoriser plusieurs vues partielles des
données.
1.1.2. La vue
La vue correspond à l'interface avec laquelle l'utilisateur interagit. Sa première tâche est de
présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes les actions
de l'utilisateur (clic de souris, sélection d'une entrées, boutons, …). Ses différents évènements
sont envoyés au contrôleur. La vue n'effectue aucun traitement, elle se contente d'afficher les
résultats des traitements effectués par le modèle. Plusieurs vues, partielles ou non, peuvent
afficher des informations d'un même modèle.
1.1.3. Le contrôleur
Le contrôleur prend en charge la gestion des évènements de synchronisation pour mettre à jour
la vue ou le modèle et les synchroniser. Il reçoit tous les évènements de l'utilisateur et enclenche
les actions à effectuer. Si une action nécessite un changement des données, le contrôleur
demande la modification des données au modèle et ensuite avertit la vue que les données ont
changé pour qu'elle se mette à jour. Certains évènements de l'utilisateur ne concernent pas les
données mais la vue. Dans ce cas, le contrôleur demande à la vue de se modifier. Le contrôleur
n'effectue aucun traitement, ne modifie aucune donnée. Il analyse la requête du client et se
contente d'appeler le modèle adéquat et de renvoyer la vue correspondante à la demande.
2. Avantages et inconvénients
Un avantage apporté par ce modèle est la clarté de l'architecture qu'il impose. Cela simplifie la
tâche du développeur qui tenterait d'effectuer une maintenance ou une amélioration sur le
projet. En effet, la modification des traitements ne change en rien la vue. Par exemple on peut

passer d'une base de données de type SQL à XML en changeant simplement les traitements
d'interaction avec la base, et les vues ne s'en trouvent pas affectées.
Le MVC montre ses limites dans le cadre des applications utilisant les technologies du web,
bâties à partir de serveurs d'applications. Des couches supplémentaires sont alors introduites
ainsi que les mécanismes d'inversion de contrôle et d'inversion de dépendance.

83 Annexe 2 : Le cycle de vie en V
Annexe 2 : Le cycle de vie en V
1. Définition
Le modèle du cycle en V ou Waterfall (en comparaison avec les méthodes dites Agile) est un
modèle conceptuel de gestion de projet imaginé suite au problème de réactivité du modèle en
cascade. Il permet, en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases
de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des
défauts sont détectés, afin d'améliorer le logiciel.
Le cycle en V est devenu un standard de l'industrie logicielle depuis les années 1980 et depuis
l'apparition de l'ingénierie des systèmes est devenu un standard conceptuel dans tous les
domaines de l'Industrie. Le monde du logiciel ayant de fait pris un peu d'avance en termes de
maturité, on trouvera dans la bibliographie courante souvent des références au monde du
logiciel qui pourront s'appliquer au système.
2. Les étapes
On liste les différentes étapes pour ce type de cycle de vie :
 Analyse des besoins et faisabilité
 Spécification fonctionnelle
 Conception architecturale
 Conception détaillée
 Codage
 Test unitaire
 Test d'intégration
 Test Système : recette usine, validation usine, VAU
 Test d'Acceptation : vérification d'aptitude au bon fonctionnement, VABF.
Une des différences entre la recette usine et la recette finale est essentiellement contractuelle.
Aussi, il n'est pas rare que le MOA (maître d'ouvrage) délègue la validation auprès d'un
organisme de validation, cet organisme étant bien souvent constitué d'experts afin de diminuer
les erreurs de validation.
3. Rôles

Dans le contexte des projets de grande envergure ont émergé des rôles pour partager et désigner
les responsabilités :
 Maîtrise d'ouvrage (MOA) qui regroupe les fonctions suivantes :
o le maître d’ouvrage stratégique (MOAS) ;
o le maître d’ouvrage délégué (MOAD) ;
o le maître d’ouvrage opérationnel (MOAO) ;
o l’assistant à maîtrise d’ouvrage (AMOA ou AMO) ;
o l’expert métier ;
o enfin l’utilisateur, au service duquel se trouvent toutes les autres fonctions.
 Maîtrise d'œuvre (MOE)
o Maîtrise d'œuvre déléguée (MOED)
o L’Équipe Architecturale
o L’Équipe de développement
o Titulaire de marché
Tableau 3 : Répartition des rôles en fonction des étapes
On retrouve dans ce découpage le V, d'où le nom de ce modèle.
4. Documents par phase

Tableau 4 : Documents en fonction des étapes
5. Risques inhérents au Cycle en V
Une fois l'ensemble des besoins capturés et les spécifications établies, il arrive que dès le niveau
de l'architecture, voire en phase de conception détaillée ou de codage, des difficultés d'ordre de
cohérence, technique et humain interviennent. C'est la fameuse différence entre la théorie et la
pratique : en théorie il n'y en a pas !
En pratique, il est difficile voire impossible de
totalement détacher la phase de conception d'un
projet de sa phase de réalisation. C'est souvent au
cours de l'implémentation qu'on se rend compte
que les spécifications initiales étaient
incomplètes, fausses, ou irréalisables, sans
compter les ajouts de nouvelles fonctionnalités
par les clients (scope creep). Lire à ce sujet Le
Mythe du mois-homme. C'est principalement
pour cette raison que le Cycle en V n'est pas
toujours adapté à un développement logiciel. La
problématique des projets
Longue durée qui sont adaptés sur ce mode
De gestion de projet est aussi souvent qu'ils risquent de ne plus « coller » aux besoins qui
évoluent dans le temps.
Figure 66 : Différence entre la théorie (les
spécifications) et la pratique (ce qui a été
produit)

D'autres modèles permettent plus facilement des modifications (parfois radicales) de la
conception initiale à la suite d'une première implémentation ou série d'implémentations. Voir
par exemple à ce sujet : Développement rapide d'applications ou Méthode agile de gestion de
projet.
6. Comité de pilotage
Pour améliorer le suivi du projet sur le plan de l'observation et des choix à effectuer, il se
constitue généralement une équipe transversale au projet : le comité de pilotage. Ce comité de
pilotage est généralement constitué d'un membre de chaque catégorie de rôle. Ce comité joue
en quelque sorte de rôle de gaine de protection autour du V. Ce comité analyse les métriques
issues des activités de chaque phase afin de réaliser la jonction entre la MOE et la MOA.

Rapport Projet de fin d'etude sur le parc informatique

Contenu connexe

Tendances

En vedette

Similaire à Rapport Projet de fin d'etude sur le parc informatique

Rapport Projet de fin d'etude sur le parc informatique