Dédicaces

A ma famille.
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 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 ?

Objectifs de recherche
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.
Objectifs spécifiques

Pour concrétiser notre objectif général de mise en place d'une solution de gestion et 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 afin de mieux maintenir l’application ;
 Améliorer le processus du relevé d’index

Hypothèses de recherche
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.

Hypothèses secondaires
Les hypothèses secondaires de notre recherche sont les suivantes :
 L’application actuelle présente des lacunes, 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.

Intérêt du sujet
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.
 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
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 rentre 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 X mois
dans l’entreprise afin de concevoir et réaliser l’application.

Délimitation du champ de l’étude

Pour mener à bien notre projet, et comme 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 X mois, période 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.

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.

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 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.

Présentation de 2iSoft
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

1.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.
 1.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.

1.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 II Cadre conceptuel
Concepts du système
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.

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.

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 III : Modélisation informatique du système

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.
Les méthodes d’analyse et de conception
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.

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.

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.

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.

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.

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.

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.

Analyse et Choix de la méthode

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.

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.

Cycle projet scrum

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.

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.

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.

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.

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

Cycle de sprint
Il se compose de plusieurs réunions :

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

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é.

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 ?

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.

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.
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 membresde l’équipe
est le meilleur)

Langage de modélisation UML

Pour Soutenir notre tâche nous avons fait recours au langage de modélisation unifié UML.

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.

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 : Analyse et conception du système
Analyse des besoins
Etude de l’existant
Critique de l’existant

Solution envisagée

Les 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

Les 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 ;
 PostgreSQL est le SGBD utilisé,
 PHP est le langage de programmation,
 Laravel est le Framework utilisé.

Spécifications fonctionnelles

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. Ensuite nous avons structuré, relié et
classé ces cas d’utilisation ainsi que les représentations graphiques UML associées.

Identification des acteurs et cas d’utilisations

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.

La figure ci-dessous illustre les différents acteurs à mettre en place :

 Gérer station
  Gérer pompe
 Gérer cuve
 Gérer carburant
 Effectuer une commande
 Réceptionner une commande
 Approvisionner une commande
 Vente carburant
 Générer facture
 Gérer caisse
 Gérer compte bancaire
 Gérer mouvement
 Gérer chèque client
 Gérer dépenses
 Gérer fournisseurs
 Gérer clients
 Gérer employés
 Gérer équipe
 Gérer fonction
 Générer bon carburant
 Gérer remise en cuve
 Relever index
 Gérer jaugeage
 Gérer utilisateur
 Gérer profil
 S’authentifier
Organisation des acteurs et cas d’utilisation en packages
Nous avons recensé huit packages notamment package Administration système, package
Inventaires, package Service, package Employé, package Tiers, package Finance, package facture, et
le package Station.

Les tableaux ci-dessous représentent les packages et les différents cas d’utilisation qui y sont
rattachés.

Package Administration système

Acteur Administrateur

Cas d’utilisations  Gérer utilisateur

 Gérer profil

Package inventaires

Acteurs Pompiste

Cas d’utilisations  Gérer bon carburant

 Gérer remise en cuve
 Relever index
  Gérer jaugeage
 Gérer recouvrement station

Package station

Acteurs Gérant

Cas d’utilisations  Gérer station

 Gérer pompe
 Gérer cuve
 Gérer carburant
 Achat carburant
 Vente carburant

Package facture

Acteurs Gérant

Cas d’utilisations  Gérer facture

Package finance

Acteurs Gérant

Cas d’utilisations  Gérer caisse

 Gérer compte bancaire
 Gérer mouvement
 Gérer chèque client
 Gérer dépenses

Package employé

Acteurs Gérant

Cas d’utilisations  Gérer employé

 Gérer équipe
 Gérer planification
 Gérer fonction

Package tiers
 Acteurs Gérant

 Cas d’utilisations  Gérer fournisseurs

 Gérer clients

Package service

Acteurs Service

 Cas d’utilisations  Gérer service

Relations entre les cas d’utilisation

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.

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.

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
Identification les rôles 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

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
ajouter un
 gérer les tiers 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

Diagramme des cas d’utilisation par acteur