Dédicaces

A ma famille.
Epigraphie
« On façonne les plantes par culture et les Hommes par l’éducation, puisque ça implique à la
fois non seulement l’effort mais aussi l’éducation » Emile, livre I

JEAN JACQUES Rousseau

Avant-propos

Ecole Supérieure des Communications Electroniques et de la Poste ESCEP-NIGER (Ex

EST) , Etablissement public à caractère scientifique, culturel et technique créer par décret
N°2023-226/PRN/MP/NTI du 02 mars 2023, a pour missions la formation, la recherche et le
perfectionnement des élèves, des étudiants et des agents des secteurs public et privé dans les
domaines des communications électroniques, de l’économie numérique et de la poste. Ainsi,
l’ESCEP-NIGER assurera la formation diplômante dans le domaine des communications
électroniques et de la poste.
Afin de préparer les futurs diplômés à l’insertion dans la vie professionnelle, ESCEP-NIGER
prévoit que chaque futur diplômé effectue un stage de fin de formation dans une entreprise.
Ce présent mémoire rentre dans ce cadre en vue de l’obtention du diplôme de fin d’étude du
cycle ingénieur. Il présente le travail que nous avons effectué durant nos six (6) mois de stage
à 2iSoft qui s’intitule :
« Conception et réalisation d’une application de gestion et suivi des stations-services »
Remerciements
Mes remerciements vont tout d’abord à Allah le Tout Puissant, le Tout Miséricordieux, le
Très Miséricordieux qui m’a guidé tout au long de ce travail, et m’a donné la force et le
courage dans la réalisation de ce document.

Je remercie mes très chers parents, qui ont toujours été là pour moi. Mes remerciements les
plus chaleureux vont aux membres de ma famille, pour leurs encouragements durant tout mon
parcours.

Je tiens également à exprimer ma gratitude envers mon encadreur, M. OUMAROU SEIDOU

Abdoulkader, Ingénieur logiciel et développeur chez 2iSoft, pour son assistance compétente,
la qualité de son suivi, ainsi que pour tous les conseils avisés qu'il m'a prodigués. Son degré
de patience et de professionnalisme exceptionnel a été inestimable. Son regard critique a
grandement contribué à la structuration du travail et à l'amélioration de la qualité des
différentes parties.
M. ABDOU MAHAMANE Abdou, chef de projet à 2iSoft, pour son aide très précieuse tout
au long de la réalisation du projet.
Je tiens à témoigner toute ma gratitude à l'ensemble du personnel de 2iSoft pour leur soutien
inestimable. Mes remerciements vont également au corps professoral de l'École Supérieure
des Communications Électroniques et de la Poste (ESCEP) pour les conseils précieux qu'ils
m'ont prodigués. Que les membres du jury trouvent, ici, l’expression de mes sincères
remerciements pour l’honneur qu’ils me font en prenant le temps de lire et d’évaluer ce
travail.

Pour finir, je remercie toutes les personnes ayant contribué de près ou de loin à la réalisation
de ce travail.
Introduction générale
Les stations-services, acteurs indispensables de notre quotidien, assurent l'approvisionnement
en carburant et offrent une gamme de services essentiels tant pour les particuliers que pour les
entreprises. La gestion efficace de ces stations-services est cruciale, non seulement pour
garantir un fonctionnement fluide et une rentabilité optimale, mais également pour répondre
aux attentes élevées de la clientèle. À l'ère de la transformation numérique, l'informatique
émerge comme un catalyseur incontournable, remodelant notre monde en un réseau
interconnecté.

L'analyse approfondie des défis spécifiques auxquels sont confrontées les stations-services
met en lumière la nécessité impérieuse d'adopter des solutions innovantes. Dans ce contexte,
les entreprises intègrent de plus en plus des outils informatiques pour optimiser leurs
opérations, offrant des avantages significatifs en termes d'efficacité et de productivité. Il
devient évident que le secteur des stations-services ne peut faire l'impasse sur cette révolution
numérique.

C'est dans ce contexte que l'entreprise 2iSoft a entrepris de développer une application de
gestion et suivi des stations-services. Notre mémoire, intitulé « Conception et réalisation
d’une application de gestion et suivi des stations-services » explore en détail les aspects
théoriques, méthodologiques, organisationnels et conceptuels de ce projet ambitieux. Ce
document sera structuré en trois grandes parties, chacune détaillant les étapes cruciales de
notre démarche :

o Cadre Théorique et Méthodologique : Présentation approfondie du projet, suivi d'une

méthodologie détaillée pour l'analyse et la conception du système.
o Cadre Organisationnel et Conceptuel : Exploration de la structure d'accueil du projet,
ainsi que la conceptualisation du système.
o Réalisation : Description des outils et technologies utilisés, présentation de
l'architecture logicielle adaptée, et aperçu de quelques interfaces de l'application.

Cette approche structurée permettra une compréhension approfondie de notre démarche, des
défis rencontrés, et des solutions apportées tout au long du processus de conception et de
réalisation de l'application de gestion des stations-services.
 Première partie :
Cadre théorique et méthodologique
Chapitre I Cadre théorique
I.1 Problématique
La gestion efficiente des stations-services demeure un enjeu majeur pour garantir un
approvisionnement en carburant sans accroc, assurer la rentabilité de l’activité et répondre aux
attentes variées de la clientèle. L'application "2iStation", actuellement en production et
développée par l'entreprise 2iSoft, présente des insuffisances notables dans sa capacité à
répondre de manière optimale aux défis de gestion spécifiques à ces établissements. Des
insuffisances dans la modélisation lors de la conception, des faiblesses au niveau de
l'architecture logicielle, et des incohérences fréquentes lors du relevé d'index des pompes et
l’approvisionnement des cuves ont été identifiées, mettant en lumière la nécessité d'apporter
des ajustements significatifs pour garantir un fonctionnement optimal de l'application.

Face à cette situation, nous nous sommes posés les questions suivantes :

 Comment identifier et remédier aux insuffisances de modélisation lors de la

conception initiale de l'application de gestion des stations-services ?
 Quelles sont les améliorations nécessaires au niveau de l'architecture logicielle pour
garantir une performance optimale, une évolutivité adéquate et une maintenance
simplifiée de l'application ?
 Quels ajustements peuvent être apportés au processus de relevé d'index des pompes et
l’approvisionnement des cuves pour éliminer les incohérences et assurer une collecte
de données précise et fiable ?
 Comment intégrer de manière transparente ces améliorations dans l'application en
production sans perturber ses fonctionnalités existantes ?
 Quelles pratiques de développement et de gestion de projet peuvent être mises en
œuvre pour éviter la récurrence de problèmes similaires à l'avenir et garantir une
évolution continue de l'application ?

I.2 Objectifs de recherche

I.2.1 Objectif général
L'objectif fondamental de notre étude consiste à établir une solution complète de gestion et
suivi dédiée aux stations-services. Notre démarche vise ainsi à reconstruire intégralement le
système existant, tout en évitant les erreurs précédemment rencontrées, afin de garantir une
performance, une fiabilité améliorée et une meilleure satisfaction des utilisateurs.
I.2.2 Objectifs spécifiques
Afin de concrétiser notre objectif général de mise en place d'une solution de gestion et de
suivi des stations-services, nous avons défini les objectifs spécifiques suivants :

 Évaluer de manière approfondie les faiblesses et forces de l'application "2iStation" en

production afin d'identifier les points nécessitant des améliorations.
 Appliquer un modèle d’architecture logiciel permettent de mieux maintenir
l’application ;
 Améliorer le processus du relevé d’index et d’approvisionnement de carburant ;

I.3 Hypothèses de recherche

I.3.1 Hypothèse générale
L’application future permettra de répondre à toutes les exigences de l’utilisateur. Elle
permettra ainsi d’apporter des meilleures solutions aux problèmes et insuffisances relatifs à
celle de l’application actuelle.

I.3.2 Hypothèses secondaires

Les hypothèses secondaires de notre recherche sont les suivantes :
 L’application actuelle présente des insuffisances, cela ne permet pas une meilleure
rentabilité.

 L’application future permettra une gestion efficace afin d’améliorer la gestion

courante de l’entreprise.

 Un modèle d’architecture sera implémenté afin de permettre une meilleure

évolutivité de l’application, mais aussi et surtout de pouvoir la maintenir sans
grandes difficultés.

I.4 Intérêt du sujet

I.4.1 Intérêts personnels

L’intérêt de ce projet nous permettra :

 D’acquérir des connaissances en gestion de stations-services ;
 De mettre en pratique les connaissances acquises à l’école ;
 De développer un esprit de synthèse ;
 De renforcer nos connaissances et faire face à la vie professionnelle.
I.4.2 Intérêt pour l’entreprise
La concrétisation de ce projet représente un atout stratégique majeur pour 2iSoft. En
développant une solution spécialisée pour la gestion des stations-services, l'entreprise élargit
son portefeuille de produits, générant ainsi de nouvelles opportunités de commercialisation et
renforçant sa position sur le marché.
Chapitre II Cadre méthodologique
II.1 Cadre de l’étude
Cette étude repose sur la mise en place d’une application de gestion et suivi des stations-
services pour l’entreprise 2ISOFT (Ingénierie Informatique Soft) à des fins commerciales.
Ce présent document entre dans le cadre de l’obtention de notre diplôme d’Ingénieur en
informatique option Génie Logiciel. Pour ce faire, nous avons effectué un stage de six (6)
mois dans l’entreprise afin de concevoir et réaliser l’application.

II.2 Délimitation du champ de l’étude

Pour mener à bien notre projet, et comme dans tout travail scientifique, nous avons jugé utile
de délimiter notre travail dans l’espace et dans le temps.
Ainsi dans le temps, notre étude se portera sur une période de six (6) mois durant laquelle
nous collecterons les données nécessaires pour une meilleure analyse avant de passer à la
mise en place de notre solution.
Dans l’espace, notre application sera faite pour notre structure d’accueil 2iSoft.

II.3 Techniques d’investigation

Nous allons rédiger notre document en nous focalisant sur la méthode qualitative afin de
mettre en place une solution qui fera face à toutes les difficultés rencontrées. Cette méthode se
base sur l’étude documentaire, l’observation, l’entretien et l’interview. Nous passerons par
des entretiens pour obtenir les informations qui nous faciliterons la compréhension de la
gestion actuelle des stations-services et les attentes de l’entreprise. Nous consulterons les
ouvrages, l’internet pour enrichir le travail que nous aurons à élaborer, et maîtriser l’ensemble
des concepts clés indispensable à l’aboutissement de ce travail.

II.4 Difficulté rencontrée

Une des principales difficultés que nous avons dû surmonter dans le cadre de ce projet est
étroitement liée au volet technique, notamment à la gestion du code. Ce défi s'est révélé
conséquent, nécessitant plusieurs semaines de recherches approfondies et de compréhension
minutieuse.
 Deuxième partie :
Cadre organisationnel et conceptuel

Chapitre : I
Chapitre III Cadre organisationnel
Avant de nous lancer dans le vif du sujet, nous allons parler de 2iSoft et ensuite nous
détaillerons l’ensemble des problèmes qui feront l’objet de notre étude.

III.1 Présentation de 2iSoft

III.2 Historique
2iSoft (Ingénierie Informatique Soft) est une entreprise fournissant des solutions
technologiques.
Créée le 18 Mai 2012, 2iSoft est née de la volonté d'accompagner les grandes entreprises et
PME à intégrer les Technologies de l'Information et de la Communication afin de booster leur
compétitivité.

Forte d’une expertise variée, leurs équipes utilisent différentes technologies pour développer
rapidement des applications fort ergonomiques.

Les progiciels de gestion intégrés sur mesure permettent une gestion coordonnée de
l'ensemble des processus des entreprises, qu'ils soient liés à la direction des affaires ou à la
gestion des ressources humaines et matérielles. Elles regroupent, autour de l’application-
métier principale, les fonctions traditionnelles telles que la gestion financière et comptable, la
Gestion des Ressources Humaines (GRH), la gestion de production et la gestion de la relation
client.

Figure 1: logo de l'entreprise 2iSoft

III.2.1 Les objectifs

L’entreprise utilise les technologies informatiques pour servir au mieux sa clientèle.

L’objectif principal est de satisfaire sa clientèle à travers la conception de logiciels, mais aussi
dans l’étude et la mise en place de réseaux informatiques, puis dans la maintenance du parc
informatique.
III.2.2 Les missions
2iSoft offre les prestations suivantes :

 La conception et l’hébergement de sites web ;

 La conception et le développement d’applications et progiciels de gestion ;
 Des travaux d’infographie (logo, cartes de visite, dépliants, flyers, design intérieur…) ;
 La formation continue en Nouvelle Technologie de l'Information et de la
Communication :
 Bureautique
 Programmation
 Bases de données
 Graphisme
 ...
 La mise en place de réseaux informatiques, de messagerie interne, d'intranet et de
connexion inter sites ;
 La maintenance informatique.

III.2.3 Organigramme
2iSoft (Ingénierie Informatique Soft) est composé :

 Directeur Général (DG)

 Contrôleur de gestion (CG)
 Directeur Technique (DT)
 Directeur Technique Adjoint (DTA)
 Directeur Commercial & Marketing (DCM)
 Responsable Administratif & Financier (RAF)
 Comptable (CPT)
 Administrateur système (Admin-sys)
 Chefs de projets (CP)
 Développeurs (Dev)
 Chargés de Maintenance & réseaux (CMR)
 Technico-commercial (TC)
 Assistante de Direction (AD)
 Chauffeur / Coursier (CC)
 Technicien surface (TS)
Nous avons effectué notre stage dans la direction technique sous la supervision d’un chef de
projet informatique comme le montre l’organigramme suivant.
Chapitre IV Cadre conceptuel
IV.1 Concepts du système
IV.1.1 Qu’est-ce qu’une station-service ?

C’est l’ensemble des installations et des activités destinées à stocker et à transférer les
hydrocarbures liquides à la pression atmosphérique de réservoirs de stockage fixes
dans les réservoirs à carburant de véhicules routiers à moteur et, le cas échéant, dans
des réservoirs mobiles. Elle est composée généralement : d’une piste destinée aux
voies de circulation, - d’une aire de distribution étanche aux hydrocarbures
généralement bétonnée, constituée par des postes de distribution, des cuves, et
éventuellement de bâtiments constitués par un bureau du gérant et/ou une salle de
vente, un magasin de stockage, une toilette et des services annexes tels que : le
vidange, le graissage, le lavage, la vulcanisation, et les petits entretiens automobiles et
les installations pour la vente des bouteilles de gaz.

IV.1.2 Définitions de quelques concepts d’une station-service

 Avant toute chose, il serait important de rappeler ce qu’est exactement une

station-service. Ainsi, il s’agit d’une infrastructure pétrolière qui est
généralement installée sur le bord d’une route ou d’une autoroute. Elle est, en
principe, destinée à fournir du carburant aux automobilistes. Mais elle remplit
également quelques autres fonctions, comme l’entretien et la maintenance des
véhicules, la réparation et l’entretien des pneus, etc. Il est également courant de
trouver un commerce au sein d’une station de carburant.
 La pompe à carburant est aussi appelée volucompteur dans le jargon
professionnel. À première vue, elle constitue une seule pièce dotée de pistolet
et d’écran. Mais en fait, il s’agit d’un assemblage de dispositifs techniques qui
ne sont pas très compliqués. L’ensemble de ces dispositifs forme la partie
principale du distributeur de carburant. En d’autres mots, c’est sa partie
mécanique.
 Approvisionnement en Carburant : Les stations-service s'approvisionnent en
carburants auprès de raffineries ou de centres de distribution. Des camions-
citernes transportent le carburant jusqu'à la station.
 Cuve de stockage : c’est un réservoir de grande capacité utilisé pour stocker les
carburants dans une station-service. Les cuves de stockage sont généralement
enterrées pour des raisons de sécurité et de conformité environnementale.
 Un carburant est une substance, comme l'essence ou le diesel, qui, lorsqu'elle
brûle, libère de l'énergie utilisée pour faire fonctionner des moteurs, comme
ceux des voitures ou des générateurs. C'est un élément essentiel pour alimenter
divers équipements et véhicules.
 Un relevé d'index dans une station-service fait référence à la mesure des
niveaux de stock de carburant dans les cuves de la station. Les employés
effectuent régulièrement ces relevés pour suivre la quantité de carburant
disponible, gérer les stocks, et anticiper les commandes d'approvisionnement
afin d'éviter les pénuries ou les excédents. Ces données sont également
utilisées pour la gestion financière, la conformité réglementaire et la
planification opérationnelle de la station-service.
 La "remise en cuve" dans une station-service se réfère généralement à une
opération où une partie du stock de carburant restant dans les cuves est retirée
pour diverses raisons. Cela peut être effectué pour des raisons de maintenance,
de conformité réglementaire, ou pour remplacer le carburant par un produit
différent.
 Recouvrement de Créances : Dans le contexte financier, le recouvrement peut
se référer au processus de récupération des paiements qui n'ont pas été
effectués à temps. Par exemple, une station-service pourrait entreprendre des
actions de recouvrement si des clients n'ont pas payé leurs factures pour le
carburant ou d'autres services.
 Recouvrement de Cuve : Si la station-service a effectué une opération de
vidange ou de nettoyage de ses cuves de stockage de carburant.
 Recouvrement après une Interruption de Service : En cas d'incident ou
d'interruption de service, le processus de remise en service ou de
rétablissement de l'approvisionnement en carburant pourrait également être
appelé "recouvrement."
 Réception et Stockage :
À la station, le carburant est déchargé des camions-citernes dans des cuves de
stockage. Ces cuves, généralement enterrées pour des raisons de sécurité et de
 conformité environnementale, servent de réservoirs de stockage pour le
carburant.
 Le jaugeage dans une station-service fait référence à la mesure du niveau de
carburant présent dans les cuves de stockage de la station. Il s'agit d'une
opération essentielle pour surveiller et contrôler la quantité de carburant
disponible.

IV.1.3 Concepts du domaine informatique

 Une application, un applicatif ou encore une appli, une app est, dans le
domaine informatique, un programme (ou un ensemble logiciel) directement
utilisé pour réaliser une tâche, ou un ensemble de tâches élémentaires d'un
même domaine ou formant un tout.
 En informatique, une application web (aussi appelée web application, de
l'anglais et français) est une application manipulable directement en ligne grâce
à un navigateur web et qui ne nécessite donc pas d'installation sur les
machines clientes.
 Une base de données est une collection organisée d’informations structurées,
généralement stockées électroniquement dans un système informatique. Une
base de données est généralement contrôlée par un système de gestion de base
de données.
 La conception est la phase créative d’un projet d’ingénierie. Le but premier de
la conception est de permettre de créer un système ou un processus répondant à
un besoin en tenant compte des contraintes. Le système doit être suffisamment
défini pour pouvoir être installé, fabriqué, construit et être fonctionnel, et pour
répondre aux besoins du client.
 Littéralement, un Framework signifie “cadre de travail”. Véritable boîte à
outils des temps modernes, ce kit de composants logiciels structurels permet
aux développeurs d’être plus efficaces dans la conception d'applications web,
entre autres, en offrant une architecture et des composants logiciels prêts à
l’emploi et réutilisables.
 Un langage de programmation est un langage informatique, permettant à un
être humain d'écrire un code source qui sera analysé par une machine,
généralement un ordinateur.
 Le système d’information (SI) est un ensemble de ressources et de dispositifs
permettant de collecter, stocker, traiter et diffuser les informations nécessaires
au fonctionnement d’une organisation (administration, entreprise…).
 Un système de gestion de base de données (SGBD) est un logiciel système
permettant aux utilisateurs et programmeurs de créer et de gérer des bases de
données.
Troisième partie :
Conception
Chapitre V Analyse des besoins et méthodologies de travail
V.1 Analyse de l’existant
V.1.1 Etude de l’existant
V.1.2 Critique de l’existant
V.1.3 Solution proposée
La solution que nous allons opter est d’améliorer l’application actuelle de l’entreprise, adopter
un modèle d’architecture logicielle conforme afin de faciliter la maintenance. Pour cela, une
nouvelle application (2IStation) sera mise place pour optimiser et améliorer la gestion
courante de l’entreprise.

V.2 Méthodes d’analyse

90 % des échecs de développement de logiciels sont dus à la recherche précipitée de la
solution et la non adéquation de solution logiciel et des besoins utilisateur. Tout ceci est dû au
manque de suivi d’une méthode d’analyse et de conception. C’est dans cette logique que nous
avons trouvé utile de suivre une méthode de conception afin de garantir la réussite de notre
projet.
Une méthode d'informatisation est composée :
 De modèles : ce sont des spécimens de résultats intermédiaires pouvant être produits
par une étape du processus ;

 De langages : pour élaborer les spécifications, et faciliter leur communication ;

 D’une démarche : processus pour effectuer les travaux préconisés, étape par étape.

V.2.1 Méthodes cartésiennes (fonctionnelles)

Avec les méthodes cartésiennes, le système étudié est vu comme un ensemble de fonctions.
Le processus de conception est vu comme un développement linéaire. Il y a décomposition
systématique des fonctions principales en sous fonctions, elles-mêmes décomposées en sous
fonctions jusqu'à un niveau considéré comme élémentaire. En exclusivement sur les
fonctions, ces méthodes finissent par occulter la prise en compte des données dans le système.
SADT (Structured-Analysis-Design-Technique) est un exemple des méthodes cartésiennes.
V.2.2 Méthodes systémiques
L’un des objectifs des méthodes systémiques est de corriger les failles des méthodes
cartésiennes en incorporant les données. Elles définissent différents niveaux de préoccupation
ou d'abstraction et proposent de nombreux modèles complémentaires. Les méthodes
systémiques sont souvent spécialisées pour la conception d'un certain type de systèmes tels
que les systèmes de conception de bases de données relationnelles (MERISE, AXIAL..).
Toutefois, ces méthodes juxtaposent les données et les traitements sans véritablement les
intégrer.

V.2.3 Méthodes orientée-objet

Les méthodes objets viennent intégrer véritablement les données aux fonctions dans le
concept objet. Pour un objet donné, les données et les fonctions sont traitées ensemble. Les
méthodes objets consistent à créer une représentation informatique des éléments du monde
réel auxquels on s'intéresse, sans se préoccuper de l'implémentation, ce qui signifie
indépendamment d'un langage de programmation. Il s'agit donc de déterminer les objets
présents et d'isoler leurs données et les fonctions qui les utilisent. Pour cela des méthodes ont
été mises au point. Entre 1970 et 1990, de nombreux analystes ont mis au point des approches
orientées objets, si bien qu'en 1994, il existait plus de 50 méthodes objets. Toutefois seules
trois (3) méthodes ont véritablement émergé :
 La méthode OMT de Rumbaugh ;

 La méthode BOOCH'93 de Booch ;

 La méthode OOSE de Jacobson.

Les promoteurs de ces trois (3) méthodes se sont fixés pour objectif de créer une méthode qui
fasse la synthèse des éléments indispensables pour faire du développement objet. Sur le plan
du langage, ils ont créé le langage UML pour la modélisation orientée objet. Pour les
processus, le consensus se fait sur les processus unifiés qui sont des méta-processus à partir
desquels le chef du projet doit décrire son véritable processus, en prenant en compte les
spécificités du problème posé, les outils et les personnes impliquées. Ce processus réel
construit sur le modèle qu’est le processus unifié, s’exprime en termes d’itérations.
V.2.4 Les méthodes formelles
Par «formel», il faut comprendre l'établissement de règles strictes afin de structurer la
«forme», le tout au sens mathématique. En effet, la rigueur de cette discipline correspond bien
à cette idée de règles. Une utilisation de ces concepts est permise grâce à un langage formel,
offrant une syntaxe ou des notations (ensemblistes, logiques, etc...) à un énoncé. Le langage
d'une méthode formelle forme sa sémantique. Chaque énoncé et/ou expression possède(nt)
ainsi une signification mathématique précise, qui n'a d'autre sens que celui décrit par la
syntaxe du texte. En l'occurrence, le but d'une méthode formelle est de proposer un processus
de production, ainsi que des outils permettant d'offrir une certaine «abstraction» (fournie par
la rigueur mathématique intrinsèque à chaque méthodologie) au logiciel à développer.

V.2.5 Les méthodes Agiles

Les méthodes de développement dites « méthodes agiles » (en anglais Agile Modeling) visent
à réduire le cycle de vie du logiciel (donc accélérer son développement) en développant une
version minimale, puis en intégrant les fonctionnalités par un processus itératif basé sur une
écoute cliente et des tests tout au long du cycle de développement.
L'origine des méthodes agiles est liée à l'instabilité de l'environnement technologique et au
fait que le client est souvent dans l'incapacité de définir ses besoins de manière exhaustive dès
le début du projet. Le terme «agile» fait ainsi référence à la capacité d'adaptation aux
changements de contexte et aux modifications de spécifications intervenant pendant le
processus de développement. En 2001, 17 personnes mirent ainsi au point le manifeste agile
dont la traduction est la suivante :
 Individus et interactions plutôt que processus et outils ;

 Développement logiciel plutôt que documentation exhaustive ;

 Collaboration avec le client plutôt que négociation contractuelle ;

 Ouverture au changement plutôt que suivi d'un plan rigide.

V.3 Methodologie de travail
V.3.1 Methodologie agile
Grâce aux méthodes agiles, le client est un pilote à part entière de son projet et obtient très
vite une première mise en production de son logiciel. Ainsi, il est possible d'associer les
utilisateurs dès le début du projet.
Plusieurs méthodes agiles sont aujourd’hui recensées : Crystal Clear, Scrum, Extreme
Programming (XP), Dynamic Software Development Method (DSDM).

 XP : eXtreme Programming processus, le consensus se fait sur les processus unifiés

qui sont des méta-processus à partir desquels le chef du projet doit décrire son
véritable processus, en prenant en compte les spécificités du problème posé, les outils
et les personnes impliquées. Ce processus réel construit sur le modèle qu’est le
processus unifié, s’exprime en termes d’itérations.
Le modèle XP date de 1996 et s’adapte aux petites équipes travaillant dans un contexte
changeant. Le but principal est de réduire les coûts liés aux changements. eXtreme
Programming fait en sorte que le projet soit plus flexible et ouvert au changement.

Scrum

Scrum est conçue pour améliorer de manière significative la productivité des équipes
de développement. C’est une méthode qui s’adapte à tout type de contexte et de projet
dès lors qu’un groupe de personnes cherche à atteindre un but commun.

V.3.2 Méthodologie Scrum

Pour la performance de notre système de gestion d’informations et pour satisfaire les
exigences du client en moindre coût et délai, nous avons utilisé la méthode agile scrum pour
la conception et le développement de notre système, en effet le processus Scrum s’adapte
parfaitement à la décomposition de notre projet de fin d’études.
V.3.2.1 Définition de la méthode Scrum
Il s’agit du framework agile le plus populaire, qui se concentre en particulier sur la façon de
gérer les tâches dans un environnement de développement en équipe. Il est développé par Ken
Schwaber et Jeff Sutherland. Scrum utilise un modèle de développement itératif et
incrémentiel, avec une durée d’itérations plus courte. En effet, Scrum définit trois rôles qui
sont :

Product Owner qui est responsable de :

  Maximiser la valeur du produit et du travail de l’Équipe de Développement
 Exprimer clairement les items du Product Backlog
 Ordonner les items du Product Backlog pour mieux réaliser les objectifs et missions

Le Scrum master qui est avant tout un coach de l’équipe et assure les tâches suivantes :

 S’assurer que Scrum est bien appliquée et respectée

 Éliminer les obstacles pouvant perturber la progression du travail.

L’équipe de projet contient généralement de 2 à 10 développeurs. Ses rôles sont les

suivantes :

 Responsable de compléter les users stories pour augmenter progressivement la valeur

du produit.
 Auto-organiser pour faire tout le travail.
 Crée les estimations du travail.

V.3.2.2 Cycle projet scrum

V.3.2.3 Artefacts Scrum

Artefacts Scrum sont essentiellement les outils que les praticiens de Scrum utilisent pour
fabriquer d’excellents produits et augmenter la visibilité et l’efficacité de la communication.
V.3.2.4 Product Backlog
Le Product backlog est une liste ordonnée de tout ce qui pourrait être requis dans le produit et
est l’unique source des besoins pour tous les changements à effectuer sur le produit.

V.3.2.5 Sprint Backlog

Le Sprint Backlog est la liste des tâches de l’équipe pour le sprint.Il comprend toutes les
stories que l’équipe s’est engagée à livrer dans le sprint et les tâches associées. Les stories
sont des livrables et peuvent être considérées comme des unités de valeur.

V.3.2.6 Burn Charts down

Il s’agit d’un graphique qui permet de surveiller l’état d’avancement d’un sprint.

Elle est fonction du temps en abscisse et des points d’histoire en ordonné. Il permet
d’anticiper les dérives.

V.3.2.7 Scrum Board (ou Task Board)

Il s’agit d’un tableau physique qui reprend les éléments du backlog du sprint en court. Il se
compose de trois colonnes et permet de suivre en temps réel l’avancement des users stories
affichés sur des post-it ou des cartes. Les colonnes de Task Board sont :

 To Do
 In progress
 Done

V.3.2.8 Cycle de sprint

Il se compose de plusieurs réunions :

 Sprint Planning
 Daily scrum meeting
 Sprint Review
 Retrospective (La rétrospective)

V.3.2.9 Sprint Planning

Planification du sprint (Sprint Planning) l’objectif est que l’équipe s’engage à un ensemble de
livrables pour le sprint et identifie également les tâches requises pour livrer les user stories
convenues. Avec l’équipe, le Product Owner présente les stories suggérées à prioriser et
l’équipe discute, parfois avec vigueur de leur position et de leur priorité.

V.3.2.10 Daily scrum meeting

Daily scrum meeting est effectuée chaque jour pendant environ 15 minutes. Le Scrum Master
pose trois questions à chaque membre de l’équipe :
  Qu’as-tu fait hier ?
 Que comptes-tu faire aujourd’hui ?
 Rencontres-tu des difficultés ?

V.3.2.11 Sprint Review

La revue du Sprint est également une réunion, d’une durée approximative de 1 heure par
semaine de Sprint. Elle permet d’inspecter et d’analyser le Sprint délivré.

Elle permet de faire aussi un point sur l’avancement de la ”Release” et d’adapter au besoin le
plan et le product Backlog.

V.3.2.12 Retrospective
Le Rétrospectif est la dernière réunion que l’équipe doit réunir pour inspecter, adapter et
optimiser ses performances en constante amélioration en équipe. Contrairement à la revue
Sprint qui comprenait des parties prenantes externes en plus de l’équipe Scrum, cette réunion
est réservée à l’équipe elle-même.

V.3.3 Les avantages et les inconvénients de la méthode Scrum

Les avantages :

 Propice à une confiance réciproque

 Transparence sur l’avancement
 Amélioration permanente
 Chaque équipe a son lot de responsabilité
 Augmente productivité et qualité
 Pilotage au quotidien

Les inconvénients :

 Peu de documentation écrite

 Si l’un des membres de l’équipe part pendant un développement, cela peut avoir un
effet inverse énorme sur le développement du projet
 L’équipe Scrum a besoin d’expérience et d’engagement.
 Scrum est principalement adapté aux petites équipes (jusqu’à 12 membres de l’équipe
est le meilleur).
V.4 Langage de modélisation UML
Pour Soutenir notre tâche nous avons fait recours au langage de modélisation unifié UML.

V.4.1 Bref historique

UML (Unified Modeling Language) est né de la fusion des trois méthodes qui s’imposaient
dans le domaine de la modélisation objet au milieu des années 1990 : OMT, Booch et OOSE.
Les principaux auteurs de la notation UML sont Grady Booch, Ivar Jacobson et Jim
Rumbaugh.

V.4.2 Généralités
UML n’est pas une méthode (i.e. une description normative des étapes de la modélisation) :
ses auteurs ont en effet estimé qu’il n’était pas opportun de définir une méthode en raison de
la diversité des cas particuliers. Ils ont préféré définir un langage graphique qui permet de
représenter, de communiquer les divers aspects d’un système d’information (aux graphiques
sont bien sûr associés des textes qui expliquent leur contenu).

UML est un métalangage car il fournit les éléments permettant de construire le modèle qui,
lui, sera le langage du projet. Il est impossible de donner une représentation graphique
complète d’un logiciel ou de tout autre système complexe, de même qu’il est impossible de
représenter une statue (à trois dimensions) par des photographies (à deux dimensions). Mais il
est possible de donner sur un tel système des vues partielles, analogues chacune à une
photographie d’une statue, et dont la juxtaposition donnera une idée utilisable en pratique sans
risque d’erreur grave. UML depuis la version 2.0 comporte treize types de diagrammes
représentant autant de vues distinctes pour représenter des concepts particuliers du système
d’information.

UML s’articule autour de 13 diagrammes, devisés en deux catégories : les diagrammes

structurels et les diagrammes de comportement. L’ensemble des 13 types de diagrammes
UML peuvent ainsi être résumé sur la figure ci- dessous :
Chapitre VI Spécification des besoins
VI.1 Capture du besoin
VI.1.1 Specification des besoins
VI.1.1.1 Besoins fonctionnels
Il s’agit dans cette section de spécifier les fonctionnalités du futur système. Nous avons
recensé un certain nombre de fonctionnalités indispensable au fonctionnement de notre
système.

Le tableau ci-dessous illustre les besoins et les fonctionnalités extraits du cahier des charges.

Besoins Fonctionnalités
Gérer les pompes Enregistrer, modifier, retirer, affecter une
pompe à une cuve
Gérer les cuves Ajouter, mise à jour, retirer, associer un
carburant à une cuve
Gérer les achats de carburants Enregistrer un achat, réceptionner un achat,
approvisionner un achat dans une cuve
Gérer les inventaires Générer un bon de carburant, relever un index,
effectuer un jaugeage, faire les recouvrements
Gérer les employés Ajouter un employé, affecter un employé à une
équipe, planifier une équipe, attribuer une
fonction à un employé
Gérer les tiers Ajouter un fournisseur, un client,
Mettre à jour les informations d’un fournisseur
et un client
Gérer les transactions financières Effectuer des virements de la caisse vers la
banque et inversement, générer une facture
Gérer les accès au système
Création et mise à jour des utilisateurs
Création et mise à jour des profils utilisateurs
Affecter des habilitations aux profils
utilisateurs
Permettre l’authentification pour accéder au
système
VI.1.1.2 Besoins techniques
La capture des besoins techniques a pour objectif, en complément avec la capture des besoins
fonctionnels, de détailler et de formaliser la partie technique de ce qui a été produit au cours
de l’étude préliminaire. Elle couvre toutes les contraintes qui ne traitent ni de la description du
métier ni de la description des besoins fonctionnels.

Notre système doit répondre aux besoins techniques suivants :

 Un système qui doit avoir un temps de réponse relativement court,

 Le système doit pouvoir donner les informations en temps réels,
 Avoir un système ergonomique, convivial, performent, fiable et simple d’utilisation,
 Avoir un logiciel évolutif et paramétrable, et, par conséquent un code clair meublé de
commentaires ;

VI.1.1.3 Modélisation du besoin

En UML, les acteurs et les cas d’utilisation sont des concepts fondamentaux pour la
spécification des exigences. A partir des besoins initialement exprimés, nous avons identifié
les acteurs et les cas d’utilisation à mettre en place.

Identification des acteurs

Il s’agit dans cette partie de bien connaître les acteurs qui vont interagir avec notre système.
Ces acteurs ne font pas partie de la solution à mettre en place, mais participe au
fonctionnement général de la solution par une interaction avec le système.

Le tableau ci-dessous illustre les différents acteurs à mettre en place et leur rôle :

Acteurs Rôle

Administrateur Acteur principale du système.

Il a le contrôle global des fonctionnalités et

utilisateurs de l’application.
 Gérant Utilisateur du système qui possède quelques
droits d’utilisation.

Responsable des employés, des fournisseurs et

est chargé des achats et commandes de
carburant.

Assure les opérations financières de la station.

Pompiste Chargé du contrôle et suivi des carburants, cuves,

et pompes de la station.

Diagramme de cas d’utilisation globale

Un cas d’utilisation représente un ensemble de séquence d’actions qui sont réalisées par le
système et qui produisent un résultat observable, intéressant pour un acteur particulier. Il
exprime les interactions acteurs/système et apporte une valeur ajoutée considérable à l’acteur
concerné. Le fait d'avoir identifié tous les acteurs (ainsi que leur mission) qui vont interagir
avec le système simplifie grandement l’identification des cas d’utilisation ; car, il suffit alors
d'analyser acteur par acteur les fonctionnalités qui lui seront utiles au regard de l’utilisation du
système, et de s’assurer que chacun dispose desdites fonctionnalités.

Pour affiner le diagramme de cas d’utilisation, UML définit trois types de relations
standardisées entre cas d’utilisation :

 La relation d’inclusion, formalisée par le mot-clé « include »

 La relation d’extension, formalisée par le mot-clé « extend »
 La relation de généralisation ou d’extension

Ci-dessous, le diagramme des cas d’utilisation de notre système.

VI.1.1.3.1 Pilotage du projet avec Scrum

Selon la méthode Scrum, la première étape est celle de la planification (appelée aussi sprint
0). Cette phase est la plus importante dans le cycle de développement Scrum, puisqu’elle
influence directement la réussite des sprints et en particulier le premier.

VI.1.1.3.1.1 Sprint 0
Dans le Sprint 0, nous allons retrouver les actions suivantes :
  Constitution de l’équipe Scrum (Product Owner, Scrum Master, Équipe de
développement).
 Écriture des users stories.
 Écriture et Priorisation du Product Backlog.
 Estimation et planification des Sprints et éventuellement des Releases.
 Mise en place de tout élément nécessaire au commencement du Sprint 1

VI.1.1.3.1.2 Identification des roles de scrum

Dans le contexte de notre projet, le chef de projet en l’occurrence Mr.Mahaman Abdou
Abdou est le Product owner, le scrum master est Mr.Oumarou Seidou Abdoul Kader et
Ousman Salimata forme l’équipe de développement

VI.1.1.3.1.3 Backlog du produit ( product backlog)

Le Backlog du produit (Product Backlog en anglais) est l’artefact le plus important de Scrum.
En effet, c’est l’ensemble des epics qui compose le produit.

Chaque epic est une grande user story qu’elle peut être divisée en plus petites user stories.

Une partie du product Backlog de notre projet est le suivant :

N° Epics N° user stories User stories Priorité

1 En tant 1.1 En tant 2
qu’utilisateur, je qu’utilisateur, je
peux peux changer
m’authentifier mon mot de passe
2 En tant 2.1 En tant 1
qu’administrateur qu’administrateur
, je peux ajouter je peux ajouter un
un utilisateur utilisateur
2.2 En tant 1
qu’administrateur
je peux créer un
rôle
2.3 En tant 1
qu’administrateur
, je peux assigner
 des permissions à
un rôle
3 En tant que 3.1 En tant que 4
gérant, je peux gérant, je peux
gérer les systèmes ajouter un
de distribution carburant
3.2 En tant que 4
gérant, je peux
ajouter une cuve
3.3 En tant que 4
gérant, je peux
ajouter une
pompe
4 En tant que 4.1 En tant que 3
gérant, je peux gérant, je peux
gérer les ajouter un
ressources employé
humaines 4.2 En tant que 3
gérant, je peux
former une
équipe
4.3 En tant que 3
gérant, je peux
planifier une
équipe
5 En tant que 5.1 En tant que 4
pompiste, je peux pompiste, je
gérer les peux effectuer
inventaires un relevé
d’index
5.2 En tant que 4
pompiste, je
peux faire une
 remise en cuve
5.3 En tant que 4
pompiste, je
peux effectuer
un jaugeage
6 En tant que 6.1 En tant que 3
gérant, je peux gérant, je peux
gérer les tiers ajouter un
fournisseur
6.2 En tant que 3
gérant, je peux
ajouter un client
7 En tant 7.1 En tant 2
qu’utilisateur, je qu’utilisateur, je
peux accéder au peux accéder au
tableau de bord tableau de bord
7.2 En tant 2
qu’utilisateur, je
peux accéder au
calendrier
8 En tant que 8.1 En tant que 5
gérant, je peux gérant, je peux
gérer les achats de réceptionner un
carburants achat
8.2 En tant que 5
gérant, je peux
approvisionner
un achat en
cuve

VI.1.1.3.1.4 Planification de release

Une fois nous avons terminé le backlog du produit, nous avons établi la réunion de
planification. Le but de cette réunion est de construire le backlog de sprint en se basant sur le
backlog de produit. Dans notre cas, nous avons découpé notre projet en 4 sprints suivants
VI.1.2 Environnement de travail
VI.1.2.1 Environnement matériel
tableau

VI.1.2.2 Environnement logiciel

VI.1.3 Langages de développement
VI.1.3.1.1.1 PHP
HyperText Preprocessor, plus connu sous son sigle PHP (acronyme récursif), est un
langage de programmation libre, principalement utilisé pour produire des pages Web
dynamiques via un serveur HTTP, mais pouvant également fonctionner comme n'importe quel
langage interprété de façon locale. PHP est un langage impératif orienté objet.

VI.1.3.1.1.2 Javascript
JavaScript est un langage de programmation de scripts principalement employé dans
les pages web interactives. C'est un langage orienté objet à prototype, c'est-à-dire que les
bases du langage et ses principales interfaces sont fournies par des objets qui ne sont pas des
instances de classes, mais qui sont chacun équipés de constructeurs permettant de créer leurs
propriétés, et notamment une propriété de prototypage qui permet d'en créer des objets
héritiers personnalisés. En outre, les fonctions sont des objets de première classe.

VI.1.3.1.1.3 CSS
Les feuilles de style en cascade1, généralement appelées CSS de l'anglais Cascading

Style Sheets, forment un langage informatique qui décrit la présentation des documents
HTML et XML.

VI.1.3.1.1.4 HTML
L’HyperText Markup Language, généralement abrégé HTML, est le format de
données conçu pour représenter les pages web. C’est un langage de balisage permettant
d’écrire de l’hypertexte, d’où son nom HTML permet également de structurer
sémantiquement et de mettre en forme le contenu des pages, d’inclure des ressources
multimédias dont des images, des formulaires de saisie, et des programmes informatiques.
VI.1.3.1.1.5 SQL
SQL (Structured Query Language, en français langage de requête structurée) est un
langage informatique normalisé servant à exploiter des bases de données relationnelles. La
partie langage de manipulation des données de SQL permet de rechercher, d'ajouter, de
modifier ou de supprimer des données dans les bases de données relationnelles.

VI.1.3.1.1.6 Framework Laravel

Laravel a été créé par Taylor Otwell en 2011 dans le but de fournir une alternative plus
élégante et expressive à CodeIgniter, un autre framework PHP de l'époque qui n'offrait pas
certaines fonctionnalités clés comme l'authentification utilisateur et l'autorisation. Depuis sa
création, Laravel a évolué pour inclure une variété de fonctionnalités qui simplifient le
développement web.

L'un des principaux avantages de Laravel est son système de routage facile à utiliser, qui
permet aux développeurs de diriger les demandes HTTP vers des contrôleurs spécifiques.
Laravel offre également un système de gestion de bases de données ORM (Object-Relational
Mapping) appelé Eloquent, qui facilite l'interaction avec les bases de données. Les vues dans
Laravel, qui sont générées à l'aide du moteur de templates Blade, permettent de créer des
interfaces utilisateur dynamiques avec une syntaxe claire et concise.

Une autre caractéristique notable de Laravel est son utilisation de Composer pour la gestion
des dépendances. Composer est un outil qui permet aux développeurs de gérer les
bibliothèques logicielles dont dépend leur projet.

En outre, Laravel possède un riche écosystème de packages et de tools, tels que Laravel Forge
pour le déploiement d'applications, Laravel Nova pour l'administration, et Laravel Echo pour
les événements en temps réel.

VI.1.4 Outil de conception et de modélisation

VI.1.5 Environnement de développement

Afin d’augmenter la productivité, les applications entreprises sont généralement développées
dans des Environnements de Développement Intégrer (IDE).

Visual Studio Code est un éditeur de code source léger mais puissant qui s'exécute sur votre
bureau et est disponible pour Windows, macOS et Linux. Il est livré avec une prise en charge
intégrée de JavaScript, TypeScript et Node.js et dispose d'un riche écosystème d'extensions
pour d'autres langages et environnements d'exécution (tels que C++, C#, Java, Python, PHP,
Go, .NET).

VI.1.5.1 Serveur d’application et de base de données

Outil graphique multi-plateforme, est le principal outil de gestion open source des bases de
données PostgreSQL. Il peut être exécuté en mode serveur web (web application) ou en mode
bureau (desktop runtime). Il fournit une interface graphique pour la création, la maintenance
et l'utilisation d'objets de base de données.

VI.1.6 Autres outils

VI.1.7 Architecture
VI.1.7.1 Architecture du système
VI.1.7.2 Architecture de l’application
Chapitre VII Release 1
VII.1 Développement du sprint 1
VII.1.1 Backlog du sprint 1
N° Epics N ° user stories User stories Priorité

1 En tant 1.1 En tant

qu’administrateur, qu’administrateur,
je peux gérer les je peux ajouter
utilisateurs. utilisateur.

1.2 En tant
qu’administrateur,
je peux modifier
les informations
d’un utilisateur.

1.3 En tant
qu’administrateur,
je peux activer ou
désactiver le
compte d’un
utilisateur.

1.4 En tant
qu’administrateur,
je peux afficher
les informations
d’un utilisateur.

2 En tant 2.1 En tant

qu’administrateur, qu’administrateur,
je peux gérer le je peux ajouter un
role d’un rôle.
utilisateur.
2.2 En tant
qu’administrateur,
 je peux activer ou
désactiver un rôle.

2.3 En tant
qu’administrateur,
je peux attribuer
un rôle a un
utilisateur.

2.4 En tant
qu’administrateur,
je peux consulter
la liste des rôles.

3 En tant 3.1 En tant

qu’administrateur, qu’administrateur,
je peux accorder je peux accorder
des permissions a des permissions a
un role. un role.

4 En tant 4.1 En tant

qu’administrateur, qu’administrateur,
je peux gerer une je peux ajouter
station une nouvelle
station.
(Idem pour les
pompes, les 4.2 En tant
cuves, et les qu’administrateur,
carburants) je peux modifier
les informations
d’une station.

4.3 En tant
qu’administrateur,
je peux activer ou
désactiver une
station.
 4.4 En tant
qu’administrateur,
je peux voir les
détails d’une
station.

4.5 En tant
qu’administrateur,
je peux consulter
la liste des
stations.

VII.1.2 Analyse
VII.1.2.1 Diagramme de cas d’utilisation
VII.1.2.2 Description textuelle des cas d’utilisation
Titre S’authentifier
Acteur Tous les utilisateurs
Description Lorsqu’un utilisateur veut accéder à l’application, il doit renseigner son
login et son mot de passe, ensuite le système vérifie s’ils sont corrects ou
pas afin d’autoriser ou de refuser l’accès.
Description des Scénario nominal :
scénarios
 L’utilisateur veut l’accéder au système, il lance un
navigateur sur sa machine ;
 Il saisit l’url de l’application sur la barre de recherche ;
 La page de connexion s’ouvre, l’utilisateur introduit son
login et son mot de passe ; [Er1]
 Le système génère le menu de l’utilisateur en fonction de
 son profil ;
 Le système affiche l’interface « Accueil » ;
Scénario alternatif :
Er1 : erreur de connexion, identifiant ou mot de passe incorrect.
Pré condition L’utilisateur doit avoir un compte.

Titre Ajouter une cuve

Acteur L’administrateur
Description Cette fonctionnalité permet d’ajouter une cuve dans une station
Description des Scénario nominal :
scénarios
1. L’utilisateur clique sur le bouton « Configurations » du
menu ;
2. Un ensemble de plusieurs sous menu sera affiché, l’utilisateur
choisit l’onglet « Cuve » ;
3. Il choisit la fonction d’ajout d’une cuve en cliquant sur le
bouton « Nouveau »
4. L’utilisateur renseigne toutes les informations
obligatoires [Av1] ;
5. L’utilisateur clique sur le bouton « Enregistrer » pour
sauvegarder les informations dans la base de données.
Scénario alternatif :
[Av1] : le libellé de la cuve saisit existe déjà, le scénario revient au point 4
Pré condition La station doit exister d’abord

Titre Créer un utilisateur

Acteur L’administrateur
Description C’est la création d’un compte pouvant se connecter à l’application
Description des Scénario nominal :
scénarios
1. L’utilisateur clique sur le bouton « Configurations » ;
2. Puis clique sur le sous menu « Gestion des utilisateurs » ;
3. L’utilisateur rempli le formulaire d’ajout d’un utilisateur ;
 [Er1]
4. L’utilisateur sauvegarde les informations en cliquant sur le
bouton « Enregistrer ».
Scénario alternatif :
[Er1] : les champs obligatoires sont vides, le système indique les champs
qui doivent être renseignés.
Pré condition

Titre Attribuer des droits à un profil

Acteur L’administrateur
Description Cette partie permet de créer un regroupement de droits (privilèges)
pouvant être affecté à un utilisateur lors de sa création
Description des Scénario nominal :
scénarios
1. L’utilisateur clique sur la partie « Configurations » dans le
menu principal ;
2. Il choisit l’onglet « Profils » dans le sous menu « Gestion des
utilisateurs »;
3. La liste des profils sera affiche avec plusieurs boutons (statut
pour activer ou désactiver un profil, actions pour la
modification ou la suppression d’un profil) ;
4. L’utilisateur clique sur le bouton modifier du profil concerne.
5. Clique sur l’un des modules, pour afficher la liste des actions
(droits) associées au module ;
6. L’utilisateur coche ou décoche les actions qu’il souhaite
attribuer au profil ;
7. La mise à jour est effectuée de manière automatique.
Scénario alternatif :

Pré condition

VII.1.3 Conception
VII.1.3.1 Diagramme de séquence