Avant-Propos

Cette étude est réalisée dans le cadre de la préparation du projet de

fin d’études, au sein de la société Tunisie Télécom, pour l’obtention du
diplôme universitaire en Informatique de Gestion.

Mon stage de fin d’études consiste à créer un projet intitulé « Jalon-

nage des factures » pour concevoir et développer un site web de gestion
des factures fournisseurs de Tunisie Télécom.

Ce stage a été une expérience enrichissante, il m’a permis de passer une

formation pour découvrir des nouveaux concepts dans le monde de déve-
loppement, de travailler avec une équipe créative, et d’établir un contact
réel et direct avec le milieu professionnel.
 Dédicaces

Je dédie ce travail :

À mes chers parents,

pour tous leurs sacrifices, leur amour, leur soutien et leurs prières tout au
long de mes études.
 Remerciements

Avant de commencer la présentation de ce rapport, je profite l’occa-

sion pour remercier à tous ceux qui, de près ou de loin, ont contribué à la
réalisation de ce travail.

En premier lieu, je tiens à exprimer mon profonde reconnaissance à

mes encadrants [Link] Jelassi et Kefi Mohamed qui est mon
cher frère, pour leurs conseils précieux, leurs soutien et surtout leur dispo-
nibilité . Je le remercie vivement pour tout.

Je remercie également toute la famille Tunisie Télécom pour leur

accueil chaleureux et pour l’expérience qu’ils m’ont offert au sein d’une
grande société.

Je tiens à exprimer toute ma gratitude et mon respect à l’équipe pé-

dagogique de la faculté des sciences économiques et de gestion de Tunis
et les intervenants professionnels responsables de ma formation, qui m’ont
permis d’évoluer rapidement dans ce domaine.

Enfin, j’adresse mes plus sincères remerciements à tous les membres

du jury qui m’ont honoré par leur présence et en acceptant de juger mon
travail.
 Table des matières

Avant-Propos 2

Dédicaces 3

Remerciements 4

Introduction générale 10

1 Cadre général du projet 11

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Présentation de l’entreprise . . . . . . . . . . . . . . . . . 13
1.2.1 Présentation générale . . . . . . . . . . . . . . . . . 13
1.2.2 Historique de Tunisie Télécom . . . . . . . . . . . . 14
1.2.3 Activités . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.4 Concurrence . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 L’étude de l’existant . . . . . . . . . . . . . . . . . . . . . 15
1.4.1 Analyse de l’existant . . . . . . . . . . . . . . . . . 15
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . 15
1.5 L’état de l’art . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.1 Les logiciels disponibles sur le marché : . . . . . . 16
1.6 Identification des besoins . . . . . . . . . . . . . . . . . . . 17
1.6.1 Identification des besoins fonctionnels . . . . . . . . 17
1.7 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . 19
1.7.1 Les méthodologies Agiles . . . . . . . . . . . . . . . 19
1.7.2 Méthodologie de gestion de projet . . . . . . . . . . 19
1.7.3 L’équipe du projet . . . . . . . . . . . . . . . . . . 20
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.9 Méthodologie de développement : BDD . . . . . . . . . . . 21
1.9.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.9.2 Outils . . . . . . . . . . . . . . . . . . . . . . . . . 22

5
 1.9.3 Les phases de BDD . . . . . . . . . . . . . . . . . . 22
1.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2 Sprint 0 : Analyse et Spécification des Besoins

23
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Identification des acteurs intervenants . . . . . . . . . . . . 24
2.3 Identification des besoins . . . . . . . . . . . . . . . . . . . 24
2.3.1 Les besoins fonctionnels . . . . . . . . . . . . . . . 24
2.3.2 Les besoins non fonctionnels . . . . . . . . . . . . . 25
2.4 Le modèle de cas d’utilisation général . . . . . . . . . . . . 26
2.5 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Plannification des sprints . . . . . . . . . . . . . . . . . . . 27
2.7 L’Architecture de l’application . . . . . . . . . . . . . . . . 27
2.7.1 L’architectue de la partie FrontEnd . . . . . . . . . 27
2.7.2 L’architecture de la partie Backend . . . . . . . . . 27
2.8 Environnement de travail : . . . . . . . . . . . . . . . . . . 28
2.8.1 Environnement matériel . . . . . . . . . . . . . . . 28
2.8.2 Environnement technique : . . . . . . . . . . . . . . 28

3 SPRINT 1
35
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Objectifs du Sprint : . . . . . . . . . . . . . . . . . . . . . 36
3.3 Le backlog du sprint 1 : . . . . . . . . . . . . . . . . . . . 37
3.4 Réalisation du sprint 1 : . . . . . . . . . . . . . . . . . . . 38
3.4.1 Diagramme de classe Sprint 1 . . . . . . . . . . . . 38
3.4.2 Diagramme d’activité Sprint 1 . . . . . . . . . . . . 39
3.4.3 Diagrammes de séquence Sprint 1 . . . . . . . . . . 41
3.5 User stories : . . . . . . . . . . . . . . . . . . . . . . . . . 43

4 SPRINT 1
49
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2 Objectifs du Sprint : . . . . . . . . . . . . . . . . . . . . . 50
4.3 Le backlog du sprint 2 : . . . . . . . . . . . . . . . . . . . 50
4.4 Diagramme de cas d’utilisation de Sprint 2 . . . . . . . . . 50
4.5 Diagramme d’activité de Sprint 2 . . . . . . . . . . . . . . 52
4.6 Diagrammes de séquence : . . . . . . . . . . . . . . . . . . 53

6
 Table des figures

1.1 Tunisie Télécom Logo . . . . . . . . . . . . . . . . . . . . . 13

1.2 Cycle de vie scrum . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Diagramme de cas d’utilisation global . . . . . . . . . . . . 26
2.2 Visual studio code . . . . . . . . . . . . . . . . . . . . . . 29
2.3 Star Uml . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4 Advaced Rest client . . . . . . . . . . . . . . . . . . . . . . 30
2.5 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.6 Html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7 Css . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.9 Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.10 Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Cas d’utilisation de sprint 1 . . . . . . . . . . . . . . . . . 38
3.2 Consulter les bordereaux . . . . . . . . . . . . . . . . . . . 39
3.3 Consulter les courriers . . . . . . . . . . . . . . . . . . . . 39
3.4 Gestion des utilisateurs . . . . . . . . . . . . . . . . . . . . 40
3.5 Gestion des fournisseurs . . . . . . . . . . . . . . . . . . . 40
3.6 Diagramme de classe facture . . . . . . . . . . . . . . . . . 41
3.7 Diagramme de classe sprint 1 . . . . . . . . . . . . . . . . 41
3.8 Diagramme d’activité sprint 1 . . . . . . . . . . . . . . . . 42
3.9 Diagramme de séquence «créer» sprint 1 . . . . . . . . . . 42
3.10 Diagramme de séquence «mettre à jour» sprint 1 . . . . . 43
3.11 Diagramme de séquence «Effacer» sprint 1 . . . . . . . . . 43
3.12 Diagramme de séquence «Afficher tout» sprint 1 . . . . . . 43
3.13 Diagramme de séquence «Authentification» sprint 1 . . . . 44
3.14 Diagramme de séquence «Import Excel» sprint 1 . . . . . . 44
3.15 Interface authentification . . . . . . . . . . . . . . . . . . . 45
3.16 Interface utilisateurs . . . . . . . . . . . . . . . . . . . . . 45
3.17 Création d’un utilisateur . . . . . . . . . . . . . . . . . . . 46

7
3.18 Création d’un utilisateur . . . . . . . . . . . . . . . . . . . 46
3.19 Modification d’un utilisateur . . . . . . . . . . . . . . . . . 47
3.20 Interface fournisseurs . . . . . . . . . . . . . . . . . . . . . 47
3.21 Interface bordereaux . . . . . . . . . . . . . . . . . . . . . 48
4.1 Diagramme de cas d’utilisation de sprint 2 . . . . . . . . . 51
4.2 Gérer les bordereaux . . . . . . . . . . . . . . . . . . . . . 51
4.3 Gérer les courriers . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Consulter les fournisseurs . . . . . . . . . . . . . . . . . . . 52
4.5 Diagramme d’activité de sprint 2 . . . . . . . . . . . . . . 53
4.6 Diagramme de séquence «Création» sprint 2 . . . . . . . . 53
4.7 Diagramme de séquence «Modification» sprint 2 . . . . . . 54
4.8 Diagramme de séquence «Efface» sprint 2 . . . . . . . . . 54

8
 Liste des tableaux

1.1 L’équipe de travail . . . . . . . . . . . . . . . . . . . . . . 21

2.1 Le Product Backlog . . . . . . . . . . . . . . . . . . . . . . 33
2.2 Le Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . 34

9
 Introduction générale

La circulation des factures fournisseurs est un flux essentiel pour Tu-

nisie Telecom. La DCF supporte les charges liées au traitement de ce flux
entrant et au contrôle de la conformité du dossier par rapport à sa com-
mande et au bon de réception. Ces charges s’avèrent complexes tenant
compte que la commande, la réception et la validation de la facture pour
paiement sont réalisées par des acteurs distincts.
Nous présenterons notre travail à travers ce rapport, qui s’articule au-
tour de quatre chapitres :

Le première chapitre intitulé « Cadre général du projet » concerne la

présentation du l’organisme d’accueil ainsi que le sujet ce site web.

Le deuxième chapitre intitulé « Analyse et Spécification des Besoins »

qui vise à identifier et décrire les besoins attendus de l’application.

Le troisième chapitre intitulé « Phase de Conception » qui s’intéresse

à l’analyse et la conception de l’application.

Le quatrième chapitre intitulé « Phase de réalisation » qui présente

les langages et les outils de programmation utilisés pour la réalisation de
l’application.

Enfin, ce rapport sera clôturé par une conclusion générale qui établit le
bilan du travail et quelques perspectives envisageables au présent projet.
1 Cadre général du projet

Sommaire
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Présentation de l’entreprise . . . . . . . . . . . . . . . . . 13
1.2.1 Présentation générale . . . . . . . . . . . . . . . . . . . . 13
1.2.2 Historique de Tunisie Télécom . . . . . . . . . . . . . . . 14
1.2.3 Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.4 Concurrence . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 L’étude de l’existant . . . . . . . . . . . . . . . . . . . . . 15
1.4.1 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . 15
1.4.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . 15
1.5 L’état de l’art . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.1 Les logiciels disponibles sur le marché : . . . . . . . . . 16
Logiciels de comptabilité . . . . . . . . . . . . . . . . . . 16
OpenCourrier : . . . . . . . . . . . . . . . . . . . 16
Qualitel courrier : . . . . . . . . . . . . . . . . . . 17
1.6 Identification des besoins . . . . . . . . . . . . . . . . . . 17
1.6.1 Identification des besoins fonctionnels . . . . . . . . . . . 17
1.7 Méthodologie de travail . . . . . . . . . . . . . . . . . . . 19
1.7.1 Les méthodologies Agiles . . . . . . . . . . . . . . . . . . 19
1.7.2 Méthodologie de gestion de projet . . . . . . . . . . . . . 19
1.7.3 L’équipe du projet . . . . . . . . . . . . . . . . . . . . . 20
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.9 Méthodologie de développement : BDD . . . . . . . . . 21
1.9.1 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

11
 1.9.2 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.9.3 Les phases de BDD . . . . . . . . . . . . . . . . . . . . . 22
1.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

12
 Ch1. Cadre général du projet
1.1 Introduction
L’étude de projet est une démarche stratégique visant à organiser le
bon déroulement d’un projet et d’assurer la conduite de toutes les phases
qui le constituent. Cette étude fera donc l’objet de ce chapitre dans lequel
nous allons présenter l’environnement de travail qui a ouvert ses portes
pour nous accueillir au sein de la société Tunisie Télécom. Ensuite, nous
allons expliquer les problèmes rencontrés qui ont donné naissance à notre
projet. Enfin, nous allons entamer ce chapitre par une présentation de la
méthodologie adoptée.

1.2 Présentation de l’entreprise

Dans cette partie nous présentons l’organisme d’accueil dans laquelle
s’est déroulé notre stage, et nous identifions ses services.

1.2.1 Présentation générale

Figure 1.1 – Tunisie Télécom Logo

Tunisie Télécom est le nom commercial de l’opérateur historique de
télécommunication en Tunisie .

13
 Ch1. Cadre général du projet
1.2.2 Historique de Tunisie Télécom
La loi portant création de l’Office national des télécommunications,
dont le nom commercial est Tunisie Télécom, est promulguée le 17 avril
1995 et entre en vigueur le 1er janvier 1996. Tunisie Télécom met en place,
exploite et commercialise le premier réseau GSM en « Mauritanie (Mattel)
» à partir de mai 2000. Elle conclut également une convention de coopé-
ration technique avec « Djibouti Télécom » pour le développement de
ses réseaux de télécommunications. En 14 avril 2020, « Mohamed Fadhel
Kraiem » est devenu le PDG.

1.2.3 Activités
Tunisie Télécom propose des services dans le domaine des télécommu-
nications fixes et mobiles. Tunisie Télécom est également un fournisseur
d’accès à Internet (Frame Relay, ADSL, X.25, LS, RNIS et WLL pour la
téléphonie rurale).

1.2.4 Concurrence
Sur le marché télécom en Tunisie, divers opérateurs sont toujours en
concurrence pour être classés premiers. Parmi eux : Tunisie Télécom, Oo-
redoo Tunisie, et Orange Tunisie...

1.3 Problématique
Précédemment, le processus de gestion des factures se faisait avec des
méthodes traditionnelles avec le contrôle humain, mais ça implique des

14
 Ch1. Cadre général du projet
problèmes

De ce fait, un processus clair et une bonne organisation sont donc re-

quis . En ce sens, notre projet consiste à réaliser un site web sécurisée qui
permet de réceptionner, trier, traiter, comptabiliser et archiver ces factures
dans le but d’automatiser ce flux de papier afin de permettre :

• La mise en place d’une traçabilité et d’un suivi rigoureux.

• L’optimisation de la gestion des factures fournisseurs.

• Une meilleure qualité de service qui satisfait le client.

• Un gain de temps et de productivité.

1.4 L’étude de l’existant

L’étude de l’existant est une phase très importante pour bien com-
prendre le système actuel et définir les objectifs. Il s’agit d’une étude suivie
de critique permettant de présenter une amélioration résumant la solution
détenue.

1.4.1 Analyse de l’existant

Actuellement, Tunisie Télécom n’utilise pas une application de jalon-
nage factures, et au cours de ces années elle applique la méthode tradition-
nelle . Le processus de gestion des factures se faisait sur papier ou à l’aide
d’un classeur Excel, mais ce contrôle humain implique des problèmes .

1.4.2 Critique de l’existant

La critique du système constitue une étape utile et importante. Elle a
pour but de porter un jugement objectif afin de déceler les insuffisances
éventuelles rencontrées au cours de l’étude de l’existant en vue de proposer
un système plus fiable que le système ancien.

Au niveau de cette étape, nous relevons certains problèmes causés par

les ancienne méthodes tel que :

15
 Ch1. Cadre général du projet
• Mauvaise traçabilité.

• Manque d’efficacité.

• Retard de paiement

• En plus du temps de la circulation du dossier jusqu’à la validation,

sans qu’il se perdre, peut être long.

D’où la nécessité de la mise en place d’une application de gestion de cour-

rier.

1.5 L’état de l’art

L’état de l’art est une étude ciblée, approfondie et critique des travaux
réalisés sur le thème de conciliation.

1.5.1 Les logiciels disponibles sur le marché :

La gestion des courriers se fait actuellement par plusieurs logiciels. Nous
allons les présenter :

Logiciels de comptabilité
Gère les dossiers des courriers entrants et sor-
OpenCourrier :
tants dans une organisation.

16
 Ch1. Cadre général du projet
Logiciel de référence en matière de gestion de
Qualitel courrier : courrier, de suivi de courrier et de traitement
du courrier.

1.6 Identification des besoins

1.6.1 Identification des besoins fonctionnels
Les besoins fonctionnels ou les besoins métiers représentent les actions
que le système doit fournir en réponse à une demande de l’utilisateur pour
répondre à ses attentes.
Notre système doit offrir les fonctionnalités suivantes :

• Dépôt de la facture par le fournisseur (ou éventuellement par les ré-

gions) au niveau du bureau d’ordre de la DCF.

• Réception de la facture fournisseur au niveau du bureau d’ordre du

DCF.

• Traitement et saisie des éléments de la facture ainsi que certaines in-

formations d’identification du fournisseur au niveau du bureau d’ordre.
La saisie à ce stade se restreint uniquement aux informations conte-
nues dans l’entête de la facture.

17
 Ch1. Cadre général du projet
• Tri des factures : ce tri se fait selon le type de la facture qu’on va le
détailler plus loin dans ce document.

• Génération des bordereaux d’envoie.

• Acheminement des factures aux équipes concernées de la Comptabilité

fournisseur

• Traitement et tri des factures selon leurs types.

• Dispatching des factures contenu dans le bordereau aux équipes concer-

nées.

• Traitement du dossier et saisie sur le système ERP.

• Mise à jour du statut de la facture.

• Envoie des factures validées à l’équipe trésorerie pour règlement

• Acheminement des factures une fois leurs dossiers clôturés au service

d’archivage

• Archivage physique des factures : classement physique rigoureux da

la facture afin d’être en mesure de la retrouver

18
 Ch1. Cadre général du projet
1.7 Méthodologie de travail
1.7.1 Les méthodologies Agiles
La méthode Agile se base sur un cycle de développement qui porte le
client au centre. Le client est impliqué dans la réalisation du début à la fin
du projet. Grâce à la méthode agile le demandeur obtient une meilleure
visibilité de la gestion des travaux qu’avec une méthode classique. L’impli-
cation du client dans le processus permet à l’équipe d’obtenir un feedback
régulier afin d’appliquer directement les changements nécessaires. Cette
méthode vise à accélérer le développement d’un logiciel. De plus, elle as-
sure la réalisation d’un logiciel fonctionnel tout au long de la durée de sa
création. Le principe de base consiste à proposer une version minimale du
logiciel puis à intégrer des fonctionnalités supplémentaires à cette base,
par processus itératif. Le processus itératif regroupe une séquence d’ins-
tructions à répéter autant de fois que possible, selon le besoin. La méthode
agile nommée Manifeste Agile repose sur quatre grands principes :

• COLLABORATION : Communication et cohésion d’équipe passent

avant les outils et les processus.

• EQUIPE : Le privilège de la relation équipe/client est mis en avant

plutôt que la négociation contractuelle.

• APPLICATION : Préférer une application bien construite à une do-

cumentation détaillée.

• ACCEPTATION : Le choix de l’acceptation du changement et de la

flexibilité au détriment d’un plan rigide.

1.7.2 Méthodologie de gestion de projet

La méthodologie adoptée par Tunisie Telecom est la méthode Scrum
pour la gestion de ses projets. C’est une méthodologie agile destinée aux
projets de moyenne et haute complexité, ayant comme principe de travail
itératif basée sur des itérations de période de temps appelées "Sprints" :
Avant de commencer un Sprint, l’équipe programme un Sprint Planning
Meeting, réunion au cours de laquelle on précise les user story à traiter.
Les User Story sont sélectionnées par ordre de priorité, puis par ordre de

19
 Ch1. Cadre général du projet
complexité. Scrum définit trois rôles sur le projet :

• Product Owner : Il porte la vision du produit à réaliser. Il travaille en

interaction avec l’équipe de développement qui doit suivre ses instruc-
tions. C’est lui qui établit la priorité des fonctionnalités à développer
ou à corriger, et qui valide les fonctionnalités terminées.

• Scrum Master : Il est responsable de la compréhension, de l’adhésion

et de la mise en œuvre de la méthode Scrum qu’il maîtrise parfaite-
ment. C’est un facilitateur qui aide à améliorer la communication au
sein de l’équipe.

• Equipe de développement : L’équipe est chargée de transformer les

besoins définis par le Product Owner en fonctionnalités utilisables.
La taille idéale de l’équipe de développement est de 3 à 9 personnes.

Figure 1.2 – Cycle de vie scrum

1.7.3 L’équipe du projet

20
 Ch1. Cadre général du projet
Rôle Mission Acteur
Présentation des
caractéristiques et des
Product Owner
fonctionnalités du produit
à développer. Brahmi Yassine
Supervision de
l’avancement du projet Et
des activités de l’équipe et
Scrum Master
éliminer les obstacles. Jelassi Nidhal
Réalisation des histoires
utilisateurs et élaboration
L’équipe des sprints. Kefi Skander

Table 1.1 – L’équipe de travail

1.8 Conclusion
Dans ce chapitre, nous avons commencé par présenter notre organisme
d’accueil et le contexte du projet. Ensuite nous avons étudié l’existant
en fournissant les critiques et les solutions proposée à mettre en place et
nous avons présenté aussi notre méthodologie de travail pour réaliser notre
projet. Le chapitre suivant traite la planification du projet.

1.9 Méthodologie de développement : BDD

Behavior driven development est une pratique de développement

1.9.1 But
Simplifier la collaboration et la circulation des information concernant
les besoins du client. En effet ,il s’agit d’une conversation sur des exemples
concrets et des règles de gestions pour lever les incertitudes et les ambi-
guïtés et mieux comprendre les besoins du clients à l’aide d’un langage
commercial et commun, aussi des stratégies d’automatisation ayant pour
but de nous indiquer rapidement si une fonctionnalité a été fournie et ce
que cette dernière fait. l’automatisation joue un rôle clé dans bdd.

21
 Ch1. Cadre général du projet
1.9.2 Outils
• CUCUMBER : c’ est l’outil d’automatisation le plus populaire, il est
aussi un outil de collaboration brillant.

• GHERKINC’est un langage éxecutable qui utilise les notations given

when then.

1.9.3 Les phases de BDD

1Ère phase : la communication et discussion de l’équipe pour connaître
les besoins réels du client.
2Ème phase : ici ce fait la transformation des ces règles et besoins en un
format testable et exécutable , ici cucumber et gherkin entrent en jeu .
3Ème phase : écrire du code d’automatisation pour transformer ces ins-
tructions given when then en tests.
4Ème phase : créer la classe qui permet d’exécuter ces besoins avec cu-
cumber.

1.10 Conclusion
Dans ce chapitre, nous avons commencé par présenter notre organisme
d’accueil et le contexte du projet. Ensuite nous avons étudié l’existant
en fournissant les critiques et les solutions proposée à mettre en place et
nous avons présenté aussi notre méthodologie de travail pour réaliser notre
projet. Le chapitre suivant traite la planification du projet.

22
2 Sprint 0 : Analyse et Spécification
des Besoins

Sommaire
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Identification des acteurs intervenants . . . . . . . . . . 24
2.3 Identification des besoins . . . . . . . . . . . . . . . . . . 24
2.3.1 Les besoins fonctionnels . . . . . . . . . . . . . . . . . . 24
2.3.2 Les besoins non fonctionnels . . . . . . . . . . . . . . . . 25
2.4 Le modèle de cas d’utilisation général . . . . . . . . . . 26
2.5 Product backlog . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 Plannification des sprints . . . . . . . . . . . . . . . . . . 27
2.7 L’Architecture de l’application . . . . . . . . . . . . . . . 27
2.7.1 L’architectue de la partie FrontEnd . . . . . . . . . . . . 27
2.7.2 L’architecture de la partie Backend . . . . . . . . . . . . 27
2.8 Environnement de travail : . . . . . . . . . . . . . . . . . 28
2.8.1 Environnement matériel . . . . . . . . . . . . . . . . . . 28
2.8.2 Environnement technique : . . . . . . . . . . . . . . . . . 28
Outils de développement et modélisation . . . . . . . . . 29
Outils de gestion de projet . . . . . . . . . . . . . . . . . 30
Langages de développement . . . . . . . . . . . . . . . . 30
Système de gestion de base de donnée . . . . . . . . . . . 32

23
 Sprint 0 : Analyse et Spécification des Besoins
2.1 Introduction
Ce chapitre est considéré comme une phase d’analyse et de spécifica-
tion des besoins afin de permettre de définir, les utilisateurs du système et
leurs besoins du projet. Dans la première partie de ce chapitre, nous allons
identifier les acteurs principaux du projet, ensuite les besoins fonctionnels
et non fonctionnels. Puis nous allons présenter l’analyse des besoins et le
Backlog produit. Enfin, nous continuons avec l’architecture physique et
logicielle de la solution et nous clôturer par la présentation de l’environ-
nement de travail adopté et la planification des sprints.

2.2 Identification des acteurs intervenants

L’identification des besoins permet de définir essentiellement les besoins
principaux pour comprendre le contexte du système.
Un acteur représente un rôle joué par une entité externe qui interagit-
directement avec le système étudié. Les acteurs interagissant avec notre
système sont :
• Responsable bureau d’ordre,
• Responsable AP,
• Responsable trésorerie,
• Contrôleur fiscale,
• Administrateur.

2.3 Identification des besoins

2.3.1 Les besoins fonctionnels
Les besoins fonctionnels sont l’expression de ce que l’application devrait
faire, elle est capable de :
• S’authentifier.
• Gestion des bordereaux.
• Gestion des factures.

24
 Sprint 0 : Analyse et Spécification des Besoins
• Gestion des courriers.

• Gestion du profil.

• Upload des courriers.

• Transférer les factures d’une équipe à l’autre.

• Valider les factures.

• Rejeter les factures.

• Catégoriser les borderaux.

• Archiver les factures.

• Télécharger les factures

• Mise à jour fournisseurs

• Mise à jour utilisateurs

• Mise à jour des bon de commandes.

• Suivre des statistiques concernant la creation des bordereaux , des

fournisseurs et la connexion des utilisateurs à l’aide d’un tableau de
bord.

• Exporter les factures en format Excel.

• Exporter les bordereaux en format Excel.

2.3.2 Les besoins non fonctionnels

Les avantages offerts par cette application sont :

• Productivité : À l’aide de sa facilité de l’utilisation, notre application

nous permet d’améliorer la productivité de notre travail.

• Performance : Les techniques et les bonnes pratiques ont donné une

minimisation du temps de réponse et de traitement.

• Sécurité : À l’accès de chaque utilisateur, il y’a une demande d’éta-

blissement de la connexion avec un mot de passe qui sera crypté.

25
 Sprint 0 : Analyse et Spécification des Besoins
2.4 Le modèle de cas d’utilisation général
Le diagramme du cas d’utilisation général est une description globale
à un ensemble d’actions réalisées par le système en interaction avec les
acteurs qui nous permet d’avoir une vue globale de haut niveau des besoins
de notre système.
Dans notre solution proposée, les deux acteurs «Développeur» et «Product
Owner» intéragissent avec le système suivant des cas d’utilisations comme
le montre la figure 2.1 :

Figure 2.1 – Diagramme de cas d’utilisation global

2.5 Product backlog

Le Product Backlog est le point central de tout projet Scrum. Il est
sous la responsabilité unique du Product Owner, mais doit également être
accessible par l’équipe. C’est à partir de ce document que les sprints seront
planifiés.

26
 Sprint 0 : Analyse et Spécification des Besoins
2.6 Plannification des sprints
La planification des sprints d’une release est l’évènement le plus im-
portant dans Scrum. Le but du découpage en sprints est de préparer le
planning de travail et d’identifier le backlog des sprints. Pour notre projet
nous avons choisi de développer 5 sprints Le tableau ci-dessous décrit la
structurations de ces sprints.

2.7 L’Architecture de l’application

Notre application se compose de deux parties, partie FrontEnd et partie
BackEnd :

2.7.1 L’architectue de la partie FrontEnd

MVVM est un design pattern ou patron de conception, très souvent
utilisé ces derniers temps par des bibliothèques Javascript. On le rencontre
également dans Silverlight et WPF. A l’origine, MVVM aurait été introduit
par Microsoft.

• Model (Modèle en français) : le modèle contient les données. Générale-

ment, ces données proviennent d’une base de données ou d’un service
externe comme un API.

• View (Vue en français) : la vue correspond à ce qui est affiché (la

page web dans notre cas). La vue contient les différents composants
graphiques (boutons, liens, listes) ainsi que le texte.

• ViewModel (Vue-Modèle en français) : ce composant fait le lien entre

le modèle et la vue. Il s’occupe de gérer les liaisons de données et les
éventuelles conversions. C’est ici qu’intervient le binding.

2.7.2 L’architecture de la partie Backend

Cette architecture, comme dans l’illustration en haut, se sépare sur
trois couches :

• Le modèle (entités de données) : représente les données de l’applica-

tion stockées dans une base de données.

27
 Sprint 0 : Analyse et Spécification des Besoins
• La vue (interface) : correspond à l’IHM (Interface Homme Machine).
Le contrôleur assure les échanges entre la vue et le modèle.

• Le contrôleur (traitement de données) : assure les échanges entre la

vue et le modèle. Le rôle du contrôleur est d’orchestrer la procédure
entre une vue et un modèle. Il analyse la requête envoyée par un client
de notre site, effectue les contrôles nécessaires afin d’appeler le modèle
convenable. Ce dernier réalise les différentes requêtes MYSQL afin de
récupérer les données en question. Ce modèle passe les données récu-
pérées au contrôleur pour qu’il puisse les retourner à la vue concernée.
Finalement, la vue affichera les interfaces demandées par l’utilisateur
de notre application.

2.8 Environnement de travail :

à ce niveau, nous couvrerons l’environnement matériel et technique
pour la réalisation de l’application.

2.8.1 Environnement matériel

Durant la réalisation de ce travail, on dispose d’un ordinateur ASUS
avec le système d’exploitation LinuX et ayant les caractéristiques sui-
vantes :

• Processeur : Intel Core i7-6500.

• Fréquence processeur : 2.50 GHz.

• Mémoire RAM : 8GB.

• Système : 64 bits.

2.8.2 Environnement technique :

Dans cette partie, nous couvrerons les outils, langageS de développe-
ment et frameworks que nous avons utilisé pour le developpement de notre
projet.

28
 Sprint 0 : Analyse et Spécification des Besoins
Outils de développement et modélisation
Visual code studio : Nous avons utilisé cet éditeur développé par Mi-
crosoft car il a gagné une très bonne satisfaction au sein de développeurs.
De plus c’est un outil open source qui facilite le développement grâce à ses
extensions.

Figure 2.2 – Visual studio code

StarUML : C’est un logiciel Open Source de modélisation Uml (Unified

Modeling Language) développé en Delphi, il est modulaire et propose plu-
sieurs générateurs de code et qui gère la plupart des diagrammes spécifiés
dans la norme UML 2.0.

Figure 2.3 – Star Uml

Advaced Rest client est un outil de débogage qui est mis en place pour
les navigateurs pour vous permet de personnaliser les requêtes envoyées à
un service RESTful. Il aide les programmeurs à développer l’application
de test RESTful Service pour leurs services.

29
 Sprint 0 : Analyse et Spécification des Besoins

Figure 2.4 – Advaced Rest client

Outils de gestion de projet

Git : C’est un logiciel de gestion de versions décentralisé. C’est un
logiciel libre créé par Linus Torvalds, auteur du noyau Linux, et distribué
selon les termes de la licence publique générale GNU version 2.

Figure 2.5 – Git

Langages de développement
HTML5 : HyperText Markup Language 5, est une version du célèbre
format HTML utilisé pour concevoir les sites Internet. Celui-ci se résume
à un langage de balisage qui sert à l’écriture de l’hypertexte indispensable
à la mise en forme d’une page Web.
CSS3 : Cascading Style Sheets, il permet de garder l’information conte-
nue dans votre document séparée des détails de sa présentation. Ces détails
de présentation d’un document sont appelés son style. La séparation du
style et du contenu permet d’éviter des duplications, une maintenance plus
facile et d’utiliser le même contenu avec différents styles pour différents
usages.
Bootstrap : C’est une collection d’outils utiles à la création du design
(graphisme, animation et interactions avec la page dans le navigateur, etc.)
de sites et d’applications web. C’est un ensemble qui contient des codes

30
 Sprint 0 : Analyse et Spécification des Besoins

Figure 2.6 – Html

Figure 2.7 – Css

HTML et CSS, des formulaires, boutons, outils de navigation et autres

éléments interactifs, ainsi que des extensions JavaScript en option.

Figure 2.8 – Git

Spring : est un framework open source pour construire et définir l’in-
frastructure d’une application Java, dont il facilite le développement et les

31
 Sprint 0 : Analyse et Spécification des Besoins
tests.

Figure 2.9 – Spring

Système de gestion de base de donnée

Mysql : est le système de gestion de base de données relationnelle le
plus populaire, ses avantages sont nombreux et expliquent sa grande po-
pularité auprès des développeurs : il est totalement open source et gratuit,
ses performances sont excellentes et il est en plus multi-threadé et multi-
utilisateurs.

Figure 2.10 – Spring

32
 Sprint 0 : Analyse et Spécification des Besoins
ID Feature User Story Priorité Estimation
En tant qu’un agent bureau
d’ordre, comptable ou
1
administrateur je veux
Authentification m’authentifier sur l’application élevé 4 heures
En tant qu’un agent bureau
2
d’ordre je veux gérer les
Gestion des bordereaux bordereaux élevé 3 jours
En tant qu’un agent bureau
3
d’ordre je veux gérer les
Gestion des courriers courriers élevé 3 jours
En tant qu’un agent bureau
3
Consultation des d’ordre je veux afficher et
fournisseurs chercher les fournisseurs élevé 1 jour
En tant qu’un agent bureau
d’ordre, un comptable, un
administrateur ou un agent
4
trésorerie je veux gérer mon
Gestion du profil profil moyen 2 jours
En tant qu’un agent bureau
d’ordre, un comptable ou
un agent de trésorerie je
5
veux passer les bordereaux à
Transferer des bordereaux l’équipe suivante élevé 5 heures
En tant qu’un comptable ou
un agent de trésorerie je
6
Validation ou rejet du veux Valider ou rejeter une
bordereau factures. élevé 1 jour
En tant qu’un agent bureau
d’ordre, un comptable ou
un agent trésorerie je veux
7
Téléchargement des Télécharger les factures ou les
courriers ou bordereaux bordereaux élevé 30 minutes
En tant qu’un
8
Catégorisation des administrateur je veux
bordereaux Catégoriser les bordereaux. élevé 3 heures
En tant qu’un
9
administrateur d’ordre je
Archivage des bordereaux veux Archiver les bordereaux. élevé 1 heure
10
En tant qu’un administrateur
Gestion des fournisseurs je veux gérer les fournisseurs élevé 4 jours
11
En tant qu’un administrateur
Gestion des utilisateurs je veux gérer les utilisateurs élevé 4 jours
En tant qu’un
12
Gestion des bons de administrateur je veux gérer
commande. les bons de commande. élevé
En tant qu’un agent bureau
d’ordre un comptable ou un
agent trésorerie je veux
Suivre des statistiques
concernant la creation des
bordereaux , des fournisseurs et
13
la connexion des utilisateurs à
Suivre un tableau de bord l’aide d’un tableau debord. moyen 5 jours
En tant qu’un agent bureau
d’ordre je veux Exporter des
14
courriers ou des bordereaux en
Exporter PDF Ou Excel 33 ou PDF
format Excel moyen

Table 2.1 – Le Product Backlog

 Sprint 0 : Analyse et Spécification des Besoins
Numéro de
sprint User Stories Durée
Gestion des bordereaux |
Factures | Utilisateurs |
Fournisseurs côté
administrateur.
• Authentification des
utilisateurs.
• Creation des Utilisateurs,
Fournisseurs.
• Recherche des
bordereaux, factures,
Utilisateurs,
Fournisseurs.
• Modification des
Utilisateurs,
Fournisseurs.
• Suppression Utilisateurs,
Fournisseurs.
• Importer d’un fichier
Excel une liste des
1
Fournisseurs.
13 jours
Gestion des bordereaux |
Factures | profils
utilisateurs côté agent
bureau d’ordre.
• Création des bordereaux
et factures.
• Recherche des bordreaux,
factures.
• Modification des factures.
• Suppression des factures.
• Modifier le profil.
• Exporter les factures ou
les bordereaux en Excel
2
ou PDF.
2 semaines
Gestion de bordereaux |
profils utilisateurs côté AP.
• Passer les bordereaux.
• Valider | rejeter les
bordereaux.
• Télécharger les
bordereaux ou les
courriers.
• Exporter les bordereaux
ou les courriers en format
Excel.
3
• Modifier le profil. 34
2 semaines
Gestion de factures | profils
côté Trésorerie.
• Valider | rejeter les
3 SPRINT 1

Sommaire
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Objectifs du Sprint : . . . . . . . . . . . . . . . . . . . . . 36
3.3 Le backlog du sprint 1 : . . . . . . . . . . . . . . . . . . . 37
3.4 Réalisation du sprint 1 : . . . . . . . . . . . . . . . . . . . 38
3.4.1 Diagramme de classe Sprint 1 . . . . . . . . . . . . . . . 38
3.4.2 Diagramme d’activité Sprint 1 . . . . . . . . . . . . . . . 39
3.4.3 Diagrammes de séquence Sprint 1 . . . . . . . . . . . . . 41
3.5 User stories : . . . . . . . . . . . . . . . . . . . . . . . . . 43

35
 SPRINT 1
3.1 Introduction
Dans le chapitre précèdent, nous avons présenté la phase d’initialisation
de notre projet. Le présent chapitre consiste à élaborer le premier sprint.
En premier lieux, nous présentons le backlog du sprint qui contient les
User Stories à traiter durant ce sprint. Par la suite nous allons présenter
la phase de réalisation.

3.2 Objectifs du Sprint :

Ce sprint permet l’admin de gérer les bordereaux, les factures, les uti-
lisateurs et les fournisseurs.

36
 SPRINT 1
3.3 Le backlog du sprint 1 :
Id
ID User Story tâche tâche Estimation
En tant qu’admin,agent
bureau d’ordre, comptable
je veux accéder à
1 l’application 1.1 s’authentifier 2 jours
récupérer mon mot de
passe à travers mon
1.1 gmail 1 jours
En tant qu’admin je veux
consulter les Affichage des
1 bordereaux 1.1 bordereaux 1 jours
Rechercher les
bordereaux par
1.2 créateur 1 jours
Archiver les
1.2 bordereaux 1 jours
En tant qu’admin je veux
1 consulter les factures 1.1 Affichage des factures 2 jours
En tant qu’admin je veux Créer de nouveaux
1 gérer les utilisateurs 1.1 utilisateurs 1 jours
1.2 Effacer les utilisateurs 1 jours
Chercher les
utilisateurs par
1.3 matricule 1 jours
Modifier les
1.4 utilisateurs 1 jours
En tant qu’admin je veux Créer de nouveaux
1 gérer les fournisseurs 1.1 fournisseurs 1 jours
1.2 Effacer les fournisseurs 1 jours
Chercher les
fournisseurs par bon
1.3 de commande 1 jours
Modifier les
1.4 fournisseurs 1 jours
Importer les
fournisseurs à partir
1.4 d’un fichier Excel 2 jours
37
 SPRINT 1
3.4 Réalisation du sprint 1 :
La figure 3.1 nous montre le cas d’utilisation du Sprint 1 : La figure

Figure 3.1 – Cas d’utilisation de sprint 1

3.2 nous montre le cas d’utilisation raffiné "Consulter les bordereaux" de

sprint 1 : La figure 3.3 nous montre le cas d’utilisation raffiné "Consulter
les courriers" de sprint 1 : La figure 3.4 nous montre le cas d’utilisation
raffiné "Consulter les utilisateurs" de sprint 1 : La figure 3.5 nous montre
le cas d’utilisation raffiné "Consulter les fournisseurs" de sprint 1 :

3.4.1 Diagramme de classe Sprint 1

Ces figures nous montrent les classes, leurs attributs et les relations
entre eux. Puisqu’il existe plusieurs types de courriers(factures) et de bor-
dereaux, j’ai divisé ce diagramme partiellement tout en préservant les re-
lations entre eux.

38
 SPRINT 1

Figure 3.2 – Consulter les bordereaux

Figure 3.3 – Consulter les courriers

3.4.2 Diagramme d’activité Sprint 1

La figure 3.4 nous montre toutes les étapes avec les exceptions possible
pour qu’un admin peut gérer les bordereaux, les factures, les fournisseurs
et les utilisateur :

39
 SPRINT 1

Figure 3.4 – Gestion des utilisateurs

Figure 3.5 – Gestion des fournisseurs

40
 SPRINT 1

Figure 3.6 – Diagramme de classe facture

Figure 3.7 – Diagramme de classe sprint 1

3.4.3 Diagrammes de séquence Sprint 1

La figure 3.5 nous montre le Diagramme de séquence «Créer un four-
nisseur ou utilisateur» :

41
 SPRINT 1

Figure 3.8 – Diagramme d’activité sprint 1

Figure 3.9 – Diagramme de séquence «créer» sprint 1

La figure 3.6 nous montre le Diagramme de séquence «mette à jour

d’une facture, bordereau, fournisseur, utilisateur» :
La figure 3.7 nous montre le Diagramme de séquence «Effacer une
facture, bordereau, fournisseur, utilisateur» :
La figure 3.8 nous montre le Diagramme de séquence «afficher les fac-
tures, bordereaux, fournisseurs, utilisateurs » :
La figure 3.9 nous montre le Diagramme de séquence «Authentification
des utilisateurs» :
La figure 4 nous montre le Diagramme de séquence «Import des utili-
sateurs à partir d’un fichier Excel» :

42
 SPRINT 1

Figure 3.10 – Diagramme de séquence «mettre à jour» sprint 1

Figure 3.11 – Diagramme de séquence «Effacer» sprint 1

Figure 3.12 – Diagramme de séquence «Afficher tout» sprint 1

3.5 User stories :

La figure 3.11 nous montre la première interface qui est l’interface d’au-
thentification. Elle permet les employés de s’authentifier :

43
 SPRINT 1

Figure 3.13 – Diagramme de séquence «Authentification» sprint 1

Figure 3.14 – Diagramme de séquence «Import Excel» sprint 1

Après L’authentification, l’administrateur accède à l’interface qui lui

permet de gérer les employés :
Dans cette interface il peut créer un utilisateur comme nous indique la
figure :
Il y’a certaines contraintes pour la création et la modification des uti-
lisateurs :

• Il ne faut choisir qu’un fichier image, c’est à dire de l’extension png,

jpg ou jpeg.

44
 SPRINT 1

Figure 3.15 – Interface authentification

Figure 3.16 – Interface utilisateurs

• la matricule et le mot de passe ne doivent pas être null.

Une fois les champs sont remplis, le boutton de création s’affiche :

L’administrateur peut aussi modifier les données de l’employé comme
nous montre la figure :
Comme nous montre la figure 3.12, l’administrateur peut aussi accéder

45
 SPRINT 1

Figure 3.17 – Création d’un utilisateur

Figure 3.18 – Création d’un utilisateur

à l’interface de gestion des fournisseurs :

46
 SPRINT 1

Figure 3.19 – Modification d’un utilisateur

Figure 3.20 – Interface fournisseurs

Voici l’interface de gestion des bordereaux :

47
 SPRINT 1

Figure 3.21 – Interface bordereaux

48
4 SPRINT 1

Sommaire
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2 Objectifs du Sprint : . . . . . . . . . . . . . . . . . . . . . 50
4.3 Le backlog du sprint 2 : . . . . . . . . . . . . . . . . . . . 50
4.4 Diagramme de cas d’utilisation de Sprint 2 . . . . . . . 50
4.5 Diagramme d’activité de Sprint 2 . . . . . . . . . . . . . 52
4.6 Diagrammes de séquence : . . . . . . . . . . . . . . . . . 53

49
 SPRINT 2
4.1 Introduction
Dans le chapitre précèdent, nous avons présenté le sprint 1 qui est la
partie administateur. Le présent chapitre consiste à élaborer le deuxième
sprint. En premier lieu, nous présenterons le backlog du sprint qui contient
les Users Stories à traiter durant ce sprint. Par la suite nous allons présenter
la phase de réalisation.

4.2 Objectifs du Sprint :

Ce sprint permet l’agent de bureau d’ordre de gérer les bordereaux et
les factures.

4.3 Le backlog du sprint 2 :

Id
ID User Story tâche tâche Estimation
En tant qu’agent bureau
d’ordre je veux gérer les Affichage des
1 bordereaux 1.1 bordereaux 1 jours
1.2 créer les bordreaux 1 jours
En tant qu’agent bureau
d’ordre je veux gérer les
1 factures 1.1 Affichage des factures 1 jours
1.2 créer les factures 1 jours
mettre à jour les
1.2 factures 1 jours
1.2 Effacer les factures 1 jours

4.4 Diagramme de cas d’utilisation de Sprint

2
La figure 4.1 nous montre le cas d’utilisation du Sprint 1 :
La figure 4.2 nous montre le cas d’utilisation raffiné "Gérer les borde-
reaux" de Sprint 2 :

50
 SPRINT 2

Figure 4.1 – Diagramme de cas d’utilisation de sprint 2

Figure 4.2 – Gérer les bordereaux

La figure 4.3 nous montre le cas d’utilisation raffiné "Gérer les courriers"
de Sprint 2 :
La figure 4.4 nous montre le cas d’utilisation raffiné "Consulter les

51
 SPRINT 2

Figure 4.3 – Gérer les courriers

fournisseurs" de Sprint 2 :

Figure 4.4 – Consulter les fournisseurs

4.5 Diagramme d’activité de Sprint 2

La figure 4.5 nous montre le diagramme d’activité de Sprint 2 :

52
 SPRINT 2

Figure 4.5 – Diagramme d’activité de sprint 2

4.6 Diagrammes de séquence :

La figure 4.6 nous montre le diagramme de séquence «Créer une facture
ou bordereau» :

Figure 4.6 – Diagramme de séquence «Création» sprint 2

La figure 4.7 nous montre le diagramme de séquence «Modifier une

facture ou bordereau» :
La figure 4.8 nous montre le diagramme de séquence «Effacer une fac-
ture ou bordereau» :

53
 SPRINT 2

Figure 4.7 – Diagramme de séquence «Modification» sprint 2

Figure 4.8 – Diagramme de séquence «Efface» sprint 2

54