Rapport PFE v1.0

Ministère de l’enseignement supérieur et de la recherche scientifique
Direction Générale des Études Technologiques

***
Institut Supérieur des Études Technologiques
de Kélibia
Département Technologies de l’Informatique
RAPPORT DE STAGE DE FIN D'ETUDES

Élaboré en vue de l'obtention du diplôme de
Licence Appliquée en Technologies de l'Informatique

Parcours
Sujet
Réalisation d'une plateforme Back office et une

application mobile d'e-tourisme
Organisme d'accueil
Easy Soft
Farouk Ben Abed
Développement des Systèmes d'Information
Année Universitaire : 2019/2020

Encadré par : Mme. Héla Khedira, Ingénieur Informatique
M. Aymen Waheb, Technologue en Informatique à ISET Kélibia
Réf :
Année Universitaire : 2019/2020

Dédicaces 1
Avec l’expression de ma reconnaissance, je dédie ce modeste travail à ceux qui, quels que soient
les termes embrassés, je n’arriverais jamais à leur exprimer mon amour sincère.
À l’homme, mon précieux offre du dieu, qui doit ma vie, ma réussite et tout mon respect : mon
cher père Jameleddine.
À la femme qui a souffert sans me laisser souffrir, qui n’a jamais dit non à mes exigences et qui
n’a épargné aucun effort pour me rendre heureux: mon adorable mère Sarra.
À mon adorable frère Hassen qui sait toujours comment procurer la joie et le bonheur pour toute
la famille.
À ma grand-mère, mes oncles et mes tantes. Que Dieu leur donne une longue et joyeuse vie.
À tous les cousins, les voisins et les amis que j’ai connu jusqu’à maintenant. Merci pour leurs
amours et leurs encouragements.
Sans oublier mon binôme Farouk pour son esprit de responsabilité, sa patience et sa
compréhension tout au long de ce projet.
Souissi Houssemeddine
Dédicaces 2
À mes chers parents, que ce modeste travail soit l'exaucement de vos vœux tant formulés, le fruit
de vos innombrables sacrifices, bien que je ne vous en acquitte jamais assez. Puisse Dieu, vous
accorder la santé, le bonheur et une longue vie et faire en sorte que jamais je ne vous déçoive.
À mes chers frère et sœur que Dieu aide vous à réussir dans la vie, que de vous parcouriez la
bonne santé et le bonheur.
À mon cher oncle Lassaad et à toute ma famille Paternelle et
Maternelle, que Dieu les protège et leur donne une longue et
Joyeuse vie.
À Wassim et Yassine et à tous mes amis qui m'ont soutenu et encouragé.
Et bien sûr mon ami et mon binôme Houssemeddine pour sa compréhension et sa patience.
Ben Abed Farouk
Remerciements
Grâce à Dieu et à nos familles, nous avons pu attendre ce moment de réalisation de notre projet
de fin d’études. Grâce aussi à notre travail acharné à la persistance et à l’esprit de responsabilité.
Nous tenons à remercier chaleureusement Advences et spécialement le manager de la société

M. Ridha Bouasker pour sa confiance. Il nous a offert une opportunité de passer un stage professionnel
de haut niveau dans un grand projet qui nous a permis d'acquérir des compétences dans la
communication professionnelle, l'organisation de travail et d'améliorer nos compétences techniques et
ceci grâce aux différents rôles que nous avons joué tout au long de ce stage.
Nous tenons à exprimer notre sincère gratitude envers Mme. Hela Khedira notre encadreur et à
tous les ingénieurs et les développeurs de l'entreprise pour leurs compréhensions et leurs accueils. Nous
avons senti que nous étions vraiment de vrais développeurs.
Nous tenons également à remercier notre enseignant et encadreur pédagogique, M. Aymen

Waheb, pour sa disponibilité, ses conseils et recommandations, ainsi que pour ses encouragements de
profiter cette opportunité et de la traduire à une expérience professionnel.
Nous tenons, par ailleurs, à exprimer nos vifs remerciements à la communité de développeurs et
à toute personne ayant contribué de près ou de loin à la réalisation de ce travail.
Sommaire
Introduction Générale.................................................................................................................1
Chapitre 1 : Présentation générale et Cadre du projet.....................................................................3
Introduction :..............................................................................................................................3
1. Présentation de l’organisme d’accueil :..................................................................................3
1.1. Présentation de la société Advences :...............................................................................3
1.2. L’organigramme de la société générale :..........................................................................3
1.3. Présentation de l’entreprise Easy Soft :............................................................................4
1.4. L’organigramme de l’entreprise Easy Soft :.....................................................................4
2. Cadre du projet:......................................................................................................................5
2.1. Contexte du projet :..........................................................................................................5
2.2. Objectifs du stage :...........................................................................................................5
Conclusion :................................................................................................................................5
Chapitre 2 : Analyse et Spécification des besoins...........................................................................6
Introduction :..............................................................................................................................6
1. Analyse et proposition de la solution :...................................................................................6
1.1. Description de l’existant :.................................................................................................6
1.2. Critique de l’existant :......................................................................................................7
1.3. Solution proposée :...........................................................................................................7
2. Spécification des besoins :.....................................................................................................9
2.1. Besoins fonctionnels :.......................................................................................................9
2.2. Besoins non fonctionnels :..............................................................................................11
3. Méthodologie de développement :.......................................................................................11
3.1. Méthode adoptée.............................................................................................................11
3.2. Les rôles et les responsabilités de chaque personne :.....................................................12
3.3. Règles interne de communication :.................................................................................13
3.4. Backlog du produit :.......................................................................................................15
3.5. Planning des sprints du projet :.......................................................................................19
Conclusion................................................................................................................................20
Chapitre 3 : Environnement de travail...........................................................................................21
Introduction :............................................................................................................................21
1. Environnement logiciel :......................................................................................................21
1.1. Présentation de l’environnement logiciel de l’application web :....................................21
1.2. Présentation de l’environnement logiciel de l’application mobile :...............................22
2. Environnement Matériel :.....................................................................................................25
Conclusion :..............................................................................................................................25
Chapitre 4 : Sprints Gestion des Produits......................................................................................26
Introduction :............................................................................................................................26
1. Conception générale de gestion des produits :.....................................................................26
1.1. Diagramme de cas d’utilisation général :.......................................................................26
1.2. Diagramme de classes général :......................................................................................27
1.3. Les micro-services impliqués :.......................................................................................27
1.4. Diagramme de cas d’utilisation raffiné de « Gestion des Produits » :............................28
2. Raffinement de cas d’utilisation « Ajouter Produit » :.........................................................28
2.1. Diagramme de séquence système « Ajouter Produit » :.................................................28
2.2. Réalisation de cas d’utilisation « Ajouter Produit » :.....................................................30
3. Raffinement de cas d’utilisation « Rechercher Produit » :...................................................31
3.1. Diagramme de séquence système « Rechercher Produit » :...........................................31
3.2. Réalisation de cas d’utilisation « Rechercher Produit » :...............................................33
4. Raffinement de cas d’utilisation « Exporter la liste des Produits » :...................................34
4.1. Diagramme de séquence système « Exporter la liste des Produits » :............................34
5. Raffinement de cas d’utilisation « Modifier Produit » :.......................................................35
5.1. Diagramme de séquence système « Modifier Produit » :...............................................35
5.2. Réalisation de cas d’utilisation « Modifier Produit » :...................................................36
Conclusion :..............................................................................................................................37
Chapitre 5 : Sprints Gestion des Tiers...........................................................................................38
Introduction :............................................................................................................................38
1. Cas d’utilisation de gestion des Tiers :.................................................................................38
1.1. Diagramme de cas d’utilisation raffiné « Gestion des Tiers » :.....................................38
2. Raffinement de cas d’utilisation « Ajouter Tiers » :............................................................39
2.1. Diagramme de séquence système « Ajouter Tiers » :.....................................................39
2.2. Réalisation de cas d’utilisation « Ajouter Tiers » :.........................................................40
3. Raffinement de cas d’utilisation « Rechercher Tiers » :......................................................41
3.1. Diagramme de séquence système « Rechercher Tiers » :...............................................41
3.2. Réalisation de cas d’utilisation « Rechercher Tiers » :...................................................43
4. Raffinement de cas d’utilisation « Modifier Tiers » :..........................................................43
4.1. Diagramme de séquence système « Modifier Tiers » :...................................................43
4.2. Réalisation de cas d’utilisation « Modifier Tiers » :.......................................................45
Conclusion :..............................................................................................................................46
Chapitre 6 : Sprints Gestion des Détails........................................................................................47
Introduction :............................................................................................................................47
1. Cas d’utilisation de gestion des détails:...............................................................................47
1.1. Diagramme de cas d’utilisation raffiné « Gestion des détails » :...................................47
2. Raffinement de cas d’utilisation « Ajouter Détail » :...........................................................48
2.1. Diagramme de séquence système « Ajouter Détail » :...................................................48
2.2. Réalisation de cas d’utilisation « Ajouter Détail » :.......................................................50
3. Raffinement de cas d’utilisation « Modifier Détail » :.........................................................51
3.1. Diagramme de séquence système « Modifier Détail » :.................................................51
3.2. Réalisation de cas d’utilisation « Modifier Détail » :.....................................................53
4. Raffinement de cas d’utilisation « Supprimer Détail » :......................................................54
4.1. Diagramme de séquence système « Supprimer Détail » :..............................................54
4.2. Réalisation de cas d’utilisation « Supprimer Détail » :..................................................55
5. Raffinement de cas d’utilisation « Supprimer Média » :......................................................56
5.1. Diagramme de séquence système « Supprimer Média » :..............................................56
Conclusion :..............................................................................................................................57
Chapitre 7 : Sprints Gestion des Catégories..................................................................................58
Introduction :............................................................................................................................58
1. Cas d’utilisation de gestion des Catégories :........................................................................58
1.1. Diagramme de cas d’utilisation raffiné « Gestion des Catégories » :.............................58
2. Raffinement de cas d’utilisation « Ajouter Catégorie » :.....................................................59
2.1. Diagramme de séquence système « Ajouter Catégorie » :.............................................59
2.2. Réalisation de cas d’utilisation « Ajouter Catégorie » :.................................................60
3. Raffinement de cas d’utilisation « Lister Catégorie » :........................................................61
3.1. Diagramme de séquence système « Lister Catégories » :...............................................61
3.2. Réalisation de cas d’utilisation « Lister Catégories » :...................................................62
4. Raffinement de cas d’utilisation « Modifier Catégorie » :...................................................63
4.1. Diagramme de séquence système « Modifier Catégories » :..........................................63
4.2. Réalisation de cas d’utilisation « Modifier Catégorie » :...............................................64
5. Raffinement de cas d’utilisation « Supprimer Catégorie » :................................................65
5.1. Diagramme de séquence système « Supprimer Catégorie » :.........................................65
Conclusion :..............................................................................................................................66
Chapitre 8 : Sprints Gestion des Tarifs..........................................................................................67
Introduction :............................................................................................................................67
1. Cas d’utilisation de gestion des Tarifs :...............................................................................67
1.1. Diagramme de cas d’utilisation raffiné « Gestion des Tarifs » :....................................67
2. Raffinement de cas d’utilisation « Ajouter Tarifs » :...........................................................68
2.1. Diagramme de séquence système « Ajouter Tarifs » :...................................................68
2.2. Réalisation de cas d’utilisation « Ajouter Tarif » :.........................................................69
3. Raffinement de cas d’utilisation « Lister Tarifs » :..............................................................70
3.1. Diagramme de séquence système « Lister Tarifs » :......................................................70
3.2. Réalisation de cas d’utilisation « Lister Tarifs » :..........................................................71
4. Raffinement de cas d’utilisation « Modifier Tarif » :..........................................................71
4.1. Diagramme de séquence système « Modifier Tarif » :...................................................71
4.2. Réalisation de cas d’utilisation « Modifier Tarif » :.......................................................73
5. Raffinement de cas d’utilisation « Supprimer Tarif » :........................................................73
5.1. Diagramme de séquence système « Supprimer Tarif » :................................................73
Conclusion :..............................................................................................................................74
Chapitre 9 : Sprints Gestion des Commandes...............................................................................75
Introduction :............................................................................................................................75
1. Cas d’utilisation « Gestion des Commandes » :...................................................................75
1.1. Diagramme de cas d’utilisation raffiné de « Gestion des Commandes » :.....................75
2. Raffinement de cas d’utilisation « Ajouter Commande » :..................................................76
2.1. Diagramme de séquence système « Ajouter Commande » :..........................................76
2.2. Réalisation de cas d’utilisation « Ajouter Commande » :..............................................78
3. Raffinement de cas d’utilisation « Rechercher Commande » :............................................79
3.1. Diagramme de séquence système « Rechercher Commande » :....................................79
3.2. Réalisation de cas d’utilisation « Rechercher Commande » :........................................80
4. Raffinement de cas d’utilisation « Modifier Commande » :................................................81
4.1. Diagramme de séquence système « Modifier Commande »..........................................81
4.2. Réalisation de cas d’utilisation « Modifier Commande » :............................................83
Conclusion :..............................................................................................................................83
Chapitre 10 : Sprints Application Mobile......................................................................................84
Introduction :............................................................................................................................84
1. Présentation de l’architecture globale de l’application mobile :..........................................84
2. Présentation de l’architecture adoptée :................................................................................85
3. Réalisation et tests :..............................................................................................................86
3.1. Navigation entre les interfaces de l’application mobile :...............................................86
3.2. Les interfaces de l’application mobile :..........................................................................86
3.3. Les tests unitaires et les tests de widgets :......................................................................89
Conclusion :..............................................................................................................................90
Conclusion Générale................................................................................................................91
Liste de figures
Figure 1.1: Organigramme de la société générale Advences..........................................................3
Figure 1.2: Organigramme de l'entreprise Easy Soft.......................................................................4
Figure 2.1 : Les fonctionnalités de la plateforme SI........................................................................6
Figure 2.2 : Schéma de l'architecture globale de la solution proposée............................................8
Figure 2.3 : Exemple d’une feuille de suivi...................................................................................14
Figure 2.4 : Exemple d'un bilan de la semaine..............................................................................15
Figure 3.1 : Présentation de la pile technologique.........................................................................22
Figure 3.2 : Comparaison de performance entre React-native et Flutter.......................................23
Figure 3.3 : Nombre de question sur Flutter et React-native.........................................................24
Figure 4.1 : Diagramme de cas d'utilisation général......................................................................26
Figure 4.2: Diagramme de classes général....................................................................................27
Figure 4.3 : Diagramme de cas d'utilisation « Gestion des Produits »..........................................28
Figure 4.4 : Diagramme de séquence système « Ajouter Produit »...............................................29
Figure 4.5 : Réalisation de cas d’utilisation « Ajouter Produit »...................................................31
Figure 4.6 : Diagramme de séquence système « Rechercher Produit ».........................................31
Figure 4.7 : Réalisation de cas d'utilisation « Rechercher Produit ».............................................33
Figure 4.8 : Diagramme de séquence système « Exporter la liste des Produits ».........................34
Figure 4.9: Diagramme de séquence système « Modifier Produit »..............................................35
Figure 4.10 : Réalisation de cas d’utilisation « Modifier Produit »...............................................37
Figure 5.1 : Diagramme de cas d'utilisation de « Gestion des Tiers »...........................................38
Figure 5.2 : Diagramme de séquence système « Ajouter Tiers »..................................................39
Figure 5.3 : Réalisation de cas d’utilisation « Ajouter Tiers »......................................................41
Figure 5.4 : Diagramme de séquence système « Rechercher Tiers »............................................41
Figure 5.5 : Réalisation de cas d’utilisation « Rechercher Tiers »................................................43
Figure 5.6 : Diagramme de séquence système « Modifier Tiers »................................................44
Figure 5.7 : Réalisation de cas d’utilisation « Modifier Tiers »....................................................46
Figure 6.1: Diagramme de cas d'utilisation de « Gestion des Détails »........................................47
Figure 6.2 : Diagramme de séquence système « Ajouter Détail ».................................................48
Figure 6.3 : Réalisation de cas d’utilisation « Ajouter Détail ».....................................................50
Figure 6.4 : Diagramme de séquence système « Modifier Détail »...............................................51
Figure 6.5 : Réalisation de cas d’utilisation « Modifier Détail »...................................................53
Figure 6.6 : Diagramme de séquence système « Supprimer Détail »............................................54
Figure 6.7 : Réalisation des cas d’utilisation Supprimer Détail et Média.....................................55
Figure 6.8 : Diagramme de séquence système « Supprimer Média »...........................................56
Figure 7.1 : Diagramme de cas d’utilisation « Gestion des Catégories »......................................58
Figure 7.2 : Diagramme de séquence système « Ajouter Catégorie »...........................................59
Figure 7.3 : Réalisation de cas d’utilisation « Ajouter Catégorie »...............................................60
Figure 7.4 : Diagramme de séquence système « Lister les Catégories ».......................................61
Figure 7.5 : Réalisation de cas d’utilisation « Lister Catégories »................................................62
Figure 7.6 : Diagramme de séquence système « Modifier Catégories ».......................................63
Figure 7.7 : Réalisation de cas d’utilisation « Modifier Catégorie ».............................................64
Figure 7.8 : Diagramme de séquence système « Supprimer Catégorie »......................................65
Figure 8.1 : Diagramme de cas d’utilisation « Gestion des Tarifs ».............................................67
Figure 8.2 : Diagramme de séquence système « Ajouter Tarif »..................................................68
Figure 8.3 : Réalisation de cas d’utilisation « Ajouter Tarif »......................................................69
Figure 8.4 : Diagramme de séquence système « Lister Tarifs »....................................................70
Figure 8.5 : Réalisation de cas d’utilisation « Lister Tarifs »........................................................71
Figure 8.6: Diagramme de séquence système « Modifier Tarif ».................................................71
Figure 8.7 : Réalisation de cas d’utilisation « Modifier Tarif »....................................................73
Figure 8.8 : Diagramme de séquence système « Supprimer Tarif »..............................................73
Figure 9.1 : Diagramme de cas d'utilisation « Gestion des Commandes »....................................75
Figure 9.2 : Diagramme de séquence système « Ajouter commande ».........................................76
Figure 9.3 : Réalisation de cas d’utilisation « Ajouter Commande »............................................78
Figure 9.4 : Diagramme de séquence système « Rechercher Commande »..................................79
Figure 9.5 : Réalisation de cas d’utilisation « Rechercher Commande »......................................81
Figure 9.6: Diagramme de séquence système « Modifier Commande ».......................................81
Figure 9.7 : Réalisation de cas d’utilisation « Modifier Commande »..........................................83
Figure 10.1 : Architecture globale de l’application mobile...........................................................84
Figure 10.2 : Présentation des couches de l'architecture adoptée..................................................85
Figure 10.3 : Schéma de navigation entre les interfaces de l’application mobile.........................86
Figure 10.4 : Interfaces de catalogue et de recherche des produits...............................................87
Figure 10.5 : Interface de catalogue des produits en mode horizontale........................................87
Figure 10.6 : Interfaces de détails d'un produit..............................................................................88
Figure 10.7 : interfaces d’affichage de la localisation et les lieux à proximité d’un produit........88
Figure 10.8 : Réalisation des interfaces de paramétrage...............................................................89
Figure 10.9 : Résultat d’exécution des tests unitaires....................................................................89
Figure 10.10 : Résultat d'exécution des tests widgets....................................................................89
Introduction Générale
L
es opportunités ne viennent pas par hasard, elles sont juste cachées derrière un travail
acharné et vous devez avoir le courage d'y faire face. Un pessimiste voit la difficulté
dans chaque opportunité, contrairement à un optimiste qui voit l'opportunité dans
chaque difficulté. Heureusement nous sommes parmi ses optimistes et nous avons accepté une
offre professionnelle en partenariat avec la société Advences dans le cadre de notre projet de fin
d’études afin de réaliser un projet dans le domaine d’e-tourisme.
Le projet est une solution au profit des acteurs e-tourisme composée par plusieurs
plateformes Back office afin de fournir tous les types de services de l’entreprise selon les
besoins. Cette solution est destinée aux acteurs impliqués dans la chaîne touristique comme les
tours opérateurs, les agences de voyages, les hôteliers, les réceptifs...
Cette solution est déjà existante pour plusieurs années mais les technologies sont
comme un quantum ne cesse pas à évoluer. Les problèmes aussi s’accumulent chaque année.
Nous allons réécrire le projet totalement mais cette fois-ci nous allons penser aux futures
versions et pour mettre en place une telle architecture nous allons consulter un expert tunisien.
Dans ce contexte s’est écrit ce rapport, nous allons essayer de résumer le nécessaire
possible à travers des chapitres bien séparés.
Ce rapport s’échelonnera sur 10 chapitres comme suit :
Pour le premier chapitre nous allons présenter la relation entre Easy Soft et Advences
ainsi que le cadre du projet.
Puis à travers le deuxième chapitre nous allons analyser la solution existante d’une
façon plus détaillée et nous allons spécifier les besoins fonctionnels de la plateforme Back office
ainsi que de l’application mobile et nous allons présenter l’architecture globale et le planning
des sprints.
1
Ensuite, dans le troisième chapitre nous exposons l’environnement logiciel les outils
utilisés et l’environnement matériel.
Par la suite, dans les chapitres qui suivirent nous détaillons la partie de conception et de
réalisation des sprints les plus importants dans le projet par la présentation des diagrammes en
général jusqu’au le raffinement des cas d’utilisation. Pour le dernier chapitre nous intéressons à
l’architecture adoptée et la réalisation des interfaces de l’application mobile.
2
Chapitre 1 : Présentation générale et Cadre du projet
Chapitre 1: Présentation générale et Cadre du

projet
Introduction :
Dans ce chapitre, nous vous présentons en premier lieu la société générale Advences et
l’entreprise Easy Soft. L’entreprise que nous étions l'un de ces employés pendant la période de
stage durant 7 mois. Ensuite nous précisons la hiérarchie de l’organisme d’accueil. Enfin nous
vous spécifions le cadre du projet.
1. Présentation de l’organisme d’accueil :

1.1. Présentation de la société Advences :
Advences est une société française Créée en 1985 par son actuel Président M. Lotfi
GABSI. Depuis 1995, Advences est un éditeur de solutions logicielles qui accompagne les tours
opérateurs, les agences de voyages, les hôteliers, les réceptifs, les offices de tourisme dans leur
projet e-tourisme. Son siège social se situe en France mais il existe d'autres bureaux en Tunisie
et à Madagascar.
1.2. L’organigramme de la société générale :

La figure 1.1 représente l’organigramme de la société Advences et donne un aperçu général sur
ces entreprises en sous-traitance.
3 1.1: Organigramme de la société générale Advences

Figure
1.3. Présentation de l’entreprise Easy Soft :

Easy Soft est une entreprise exportatrice pour Advences dont la production est destinée
à l’étranger on dit alors que Easy Soft est en sous-traitance de Advences. C’est à dire Advences
demande à Easy Soft de réaliser une partie de sa production ou des entreprises auxquelles sont
agréées certaines parties de travail.
Le sous-traitant fabrique un produit conçu par Advences ou, souvent, en commun avec
lui. Le produit est fabriqué par Easy Soft pour le compte exclusif du commanditaire (Advences)
et ne porte pas le logo de l’entreprise Easy Soft.
1.4. L’organigramme de l’entreprise Easy Soft :

La figure 1.2 montre l’organigramme de l’entreprise Easy Soft et donne un aperçu général sur les
services de l’entreprise, de ses employés et de leur domaine d'activité.
Figure 1.2: Organigramme de l'entreprise Easy Soft
4
2. Cadre du projet:
2.1. Contexte du projet :
Le projet à développer est une solution technologique pour tous les acteurs de la chaîne
touristique (Tours Opérateur, Distributeurs, Agences de voyages, Réceptifs, Hôteliers).
C’est un système d’information e-tourisme qui permet au client de gagner du temps et

de l'argent par des plateformes back to front. À l’aide de cette solution le client peut gérer
facilement son business. De plus, nous allons finaliser avec une application mobile destinée aux
clients finaux d’une agence de voyages. Cette application va ressembler à un catalogue de
différents types de produit du client.
2.2. Objectifs du stage :

Parmi les objectifs sur lesquels nous travaillons dans le cadre de notre projet de fin
d'études : C'est d'approfondir nos compétences ainsi que nos connaissances notamment dans
les projets professionnels par la réalisation d’une solution technologique destinée aux acteurs
impliqués dans le domaine de e-tourisme.
L’objectif principal de ce projet c’est de fournir aux clients une solution technologique
moins chère, plus évolutive afin de satisfaire les besoins des clients et d’utiliser une technologie
open-source et populaire sur le marché ce qui facilite l’intégration de nouveaux développeurs.
Nos objectifs ne se situent pas seulement dans les sujets techniques ou fonctionnels mais
aussi dans la communication avec tous les intervenants impliqués dans ce projet.
Notre objectif est également de maîtriser les nouvelles technologies et d'apprendre les
procédures de travail en équipe. L’expérience que nous allons acquérir de ce stage va nous
permettre d'être plus mature dans le marché de travail.
Conclusion :
Après la présentation de l’organisme d’accueil et la définition du cadre de projet nous

avons défini nos objectifs. Dans la suite, nous commençons l’achèvement de nos objectifs mais
avant tout nous devons analyser la solution existante afin de proposer une solution qui satisfaire
les besoins des clients et de la société.
5
Chapitre 2 : Analyse et Spécification des besoins
Introduction :
Dans ce chapitre nous allons entamer la partie analyse de la solution existante. Ensuite
nous allons proposer la nouvelle solution et nous allons spécifier les besoins fonctionnels et non
fonctionnels. Enfin, nous allons définir la méthodologie adoptée.
1. Analyse et proposition de la solution :

1.1. Description de l’existant :
La solution existante est un système d’information (SI) utilisé par plus de 20 clients
impliqués dans le domaine de e-tourisme.
La figure 2.1 donne un aperçu général sur les fonctionnalités de la plateforme SI :
Figure 2.3 : Les fonctionnalités

6 de la plateforme SI
La plateforme est accessible en mode client léger sur le web via une URL et ce à partir de tout
poste connecté à Internet.
Le système d’information permet aux clients de :
- Gérer les données marketing tels que (les hôtels, les vols, les forfaits...)
- Gérer et Informatiser les processus métiers de l’entreprise.
- Administrer la distribution en multi-canal : points de vente, call center, site B2C, site B2B...
À partir d’une version standard disponible :
Le système est paramétré et adapté sur mesure au besoin du professionnel afin de prendre en
compte toutes les spécificités de chaque client.
Techniquement ce système d’information est développé en Coldfusion comme langage backend.
1.2. Critique de l’existant :

Après plusieurs années d’utilisation de la solution existante, Nous pouvons dégager les
points faibles du Système.
La plateforme est conçue comme un bloc contenant plusieurs fonctionnalités. Cela

diminue la tolérance du système aux erreurs qui peuvent survenir à tout moment. Ses
Composants sont interconnectés et interdépendants puisqu’elle est basée sur une architecture
monolithique.
La solution est développée avec un langage payant (Coldfusion) ce qui ajoute des coûts
supplémentaires pour héberger le projet sur des serveurs d’applications spécifiques. En plus, Les
développeurs ont besoins de faire une formation en Coldfusion pour s’intégrer dans la
maintenance du système.
Les clients se plaignent des coûts élevés de la solution puisqu’elle est toute en un. Donc,
ils sont parfois obligés d’acheter la totalité du système pour profiter seulement des modules de
gestion des produits ou de finance.
1.3. Solution proposée :

La solution technologique proposée est composée par plusieurs plateformes logicielles
permettront de bénéficier d'une gestion intégrée de tous les processus métier de l'entreprise.
7
Cette solution est basée sur une architecture micro-services afin de sortir avec un
système modulaire et scalable.
Cette architecture est conçue par notre expert M. Aniss Boumrigua IT Manager chez rue
de commerce. La figure suivante donne une vision générale sur l’architecture globale du
système.
Figure 2.4 : Schéma de l'architecture globale de la solution proposée
La solution est composée par 3 plateformes logicielles de Back office indépendantes qui
permettent le client de profiter des plateformes en fonction de ses besoins.
Les plateformes logicielles sont :
 Leisure platform (LP) : C’est une plateforme pour la gestion des données marketing des
produits hôtel, vol, prestation terrestre, packages, suppléments...
8
 Service Desk (SD) : C’est une plateforme d’assistance aux utilisateurs en passant par la
gestion des incidents et des problèmes.
 Finance platform (FI) : C’est une plateforme de gestion financière comme les paiements
et les opérations bancaires.
La solution est développée avec la Framework Symfony. C’est un Framework open source
et très populaire dans le marché ce qui facilite l’intégration des développeurs dans la
maintenance.
2. Spécification des besoins :

2.1. Besoins fonctionnels :
Le projet à réaliser doit satisfaire les exigences de la totalité des utilisateurs. Nous
présentons dans ce qui suit les besoins fonctionnels de la plateforme de Back office :
 Gestion des produits : c'est le principal besoin fonctionnel dans ce projet qui permet à
l’utilisateur de : Gérer les produits qui peuvent être de type Hébergement, Transport,
Activité, Forfait, Location de voiture...
Ce module contient des sous modules qui permettent aussi :
 La gestion des suppléments/catégories du produit : Pour les produits de
type forfait on parle de la gestion des suppléments et pour les autres types on
parle de la gestion des catégories.
 La gestion des photos : associer des photos aux produits.
 La gestion des détails du produit : la gestion des détails du produit tel que
les photos, les vidéos et la description de chaque détail.
 La gestion des règles segments : Les segments sont disponibles pour les
produits de type forfait. Un forfait peut être composé par plusieurs produits
avec ou sans catégories ou composé par des règles.
 La gestion des segments de vol : Il s’agit parfois d’un changement du vol
lors de l’escale. Ce module est responsable de gérer les vols filles d’un circuit
bien défini.
9
 La gestion des tarifs : On peut gérer les tarifs pour chaque catégorie ou
supplément d’un produit et l’utilisateur peut définir les prix du service et la
devise et d’autres données tels que la date et les jours de vente ou d’achat.
 La gestion des localités du produit : Chaque produit possède une ou
plusieurs localité(s). Donc ce module permet de définir la localisation du
produit.
 La gestion des données d’optimisation pour les moteurs de recherche
 La gestion des tags : Facilite la recherche dans les sites front ou définir le
type d’offre (ex : Weekend, Promotion) ou la cible (ex : Famille, Couple,
Groupe).
 Gestion des utilisateurs : Ce module permet d’ajouter, consulter et modifier les
utilisateurs du tenant connecté.
 Gestion des tiers : Ce module doit permet l’utilisateur d’ajouter, consulter modifier et
exporter les tiers (fournisseur, producteur, apporteur d’affaire...)
 Gestion des paramètres : Ce module doit permet l’utilisateur de gérer les paramètres de
la plateforme selon le tenant connecté.
 Gestion des localités : Ce module permet l’utilisateur de gérer les localités comme les
villes, les gares, les zones navigables, les aéroports ...
 Configuration du compte : Ce module permet l’utilisateur de préciser les préférences
telles que la devise par défaut, l’adresse de facturation, les numéros de téléphone ...
 Gestion des documents électroniques : Ce module permet à l’utilisateur d’organiser et
gérer les répertoires et leur contenu.
 Gestion des règles de tarification : Ce module permet le client de gérer les règles de la
tarification comme les marges, les commissions et les promotions.
 Gestion des articles : Ce module permet l’utilisateur de gérer les connaissances par
l’édition d’un article ou d’une documentation.
 Gestion des commandes : Ce module permet l’utilisateur de gérer les commandes.
Nous citons dans la partie suivante les besoins fonctionnels de l’application mobile spécifier par :
le responsable du projet M. Ridha Bouasker :
10
 Catalogue pour chaque type de produit : Le catalogue permet à l’utilisateur de

découvrir les produits du client.
 Recherche des produits : L’utilisateur peut faire une recherche afin de faciliter l’accès
aux produits.
 Afficher les détails des produits : L’utilisateur peut consulter la fiche du produit et les
détails.
 La localisation du produit : l’utilisateur peut savoir la localisation d’un produit. La
localité du produit s’affiche sur une carte.
 Afficher les lieux à proximité du produit : L’utilisateur peut afficher les lieux à
proximité du produit selon le choix comme les restaurants, les banques, les pharmacies,
les stations...
2.2. Besoins non fonctionnels :
Parmi les besoins non fonctionnels du site Back Office nous citons :
 Temps de réponse : Utilisation des services minifiés afin d’optimiser le temps

d’ouverture des écrans.
 Sécurité : Expiration du token d’authentification après quelques temps.
 Capacité : Scalable selon l’utilisation
 Ergonomie :
 Les éléments dans l’écran ne sont pas denses.
 Interface Utilisateur simple
 Accessibilité aux modules en 2 clics (utilisation des pop-ups)
 Internationalisation et vérification de l’orthographe.
 Documentation :
 Documentation de chaque élément/traitement (destinée aux développeurs).
 Guide d’utilisation (destiné aux utilisateurs).
Parmi les besoins non fonctionnels de l’application mobile nous mentionnons :
 Accessibilité : l’application disponible en deux modes en ligne et hors ligne
 Internationalisation et vérification de l’orthographe.
 Utilisation des données internet et mémoire vive optimisée.
11
 Présence des tests unitaires et tests widgets

 Application disponible en mode nuit.
3. Méthodologie de développement :
3.1. Méthode adoptée
Après l’analyse du périmètre et les spécificités du projet, l’équipe de développement a

réalisé que les facteurs clés de succès du projet résident dans la collaboration et la
communication entre les membres de l’équipe et la forte implication de la direction du client
dans la réalisation du projet.
L’utilisation d’une méthode agile est une priorité afin de réussir notre mission dans les
meilleures conditions. Nous avons choisi la méthode Scrum qui présente une implémentation de
l’approche agile.
3.2. Les rôles et les responsabilités de chaque personne :

Dans cette partie Nous présentons le rôle et la responsabilité de chaque personne
impliquée dans le projet.
Product Owner : Advences joue le rôle de product owner afin de déterminer les priorités et les
besoins fonctionnels des tenants attendus.
Scrum Master : M.Ridha Bouasker joue le rôle de Scrum Master. C’est qui assure la bonne
communication entre les membres de l’équipe par la mise en place des règles internes pour la
communication. Aussi parmi ses responsabilités :
 Coordinateur entre les équipes de développement et les clients.

 Gestionnaire et organisateur des plannings et la composition de chaque équipe.
 Suivi et validation des tâches traitées.
 Démonstration des incréments aux clients.
Teams : Nous sommes 25 personnes qui forment 5 équipes comme suit :
 Équipe Applications Front (CF Travel)

 Équipe Leisure platform (nous font partie de cette équipe)
12
 Équipe Service Desk

 Équipe Assurance Qualité (Impact Player)
 Équipe Finance Platform
Parmi les rôles que nous avons eu pendant notre stage :

 Développeur côté Manager :
 Mettre en place les écrans selon les spécifications demandées.
 Identifier, analyser et corriger les bugs.
 Proposer et implémenter des solutions afin de résoudre un problème technique ou
mettre en place une nouvelle fonctionnalité telle que (Webpack encore, la
pagination, export d’un fichier Excel, Drag and Drop, Moteur de recherche,
l’insertion dynamique des translations...).
 Préparation de la documentation (règles techniques et ergonomiques).
 Support aux développeurs.
 Développeur côté API :
 Gestion des filtres des services avec API platform.
 Résoudre les problèmes techniques tels que (séparation des données des tenants,
gestion des devises, la pagination, les filtres personnalisés.).
 Résoudre les problèmes de lenteur par la mise en place des services minifiés.
 Préparation de la documentation pour les services mis en place.
 Formateur :
 Formation de 4 Stagiaires afin de les intégrer dans les projets : Finance, To Know
et Service Desk par des visio-conférences, des tutoriaux et des exemples.
 Emna Darej
 Maroua Khalfi
 Hanen Gtari
 Boughanmi Salim
 Formation pour Aymen Zguir (administrateur réseaux) afin de l’intégrer en tant
que développeur dans le projet.
3.3. Règles interne de communication :
13
Nous utilisons Skype comme outils de communication. Chaque personne possède une
fenêtre de suivi afin de suivre l’avancement des tâches affectées. Le développeur doit préciser
son avancement toutes les 2 heures au maximum.
Chaque personne possède une feuille de calcul en ligne pour lister ses points en précisant
le numéro, le statut, la priorité et une partie pour un commentaire ou pour la prochaine étape. La
figure suivante donne un aperçu sur une feuille de suivi :
Figure 2.5 : Exemple d’une feuille de suivi

Un point peut être :
 Une tâche de développement ou de documentation

 Une proposition/optimisation
 Un problème technique, ergonomique ou d’architecture
 Un Bug
La validation d’un point se fait par e-mail ou par Skype selon le type du point, une fois validé le
point est fermé.
Nous faisons des réunions journalières, durant ses réunions nous concluons les points traités, les
sujets à discuter puis nous définissons les points prioritaires à faire.
14
Chaque semaine, le Scrum master prépare le bilan qui sera partager avec les autres cadres de la
société Advences.
La figure suivante montre un exemple d’un bilan de la semaine 14 (30 mars 2020) :
Figure 2.6 : Exemple d'un bilan de la semaine
Généralement la durée d’un sprint dans sa version 1 ne dépasse pas une semaine. C’est à
dire chaque semaine nous faisons une démonstration aux clients avant de passer à la version
suivante.
Au cours de la démonstration le Scrum master note les remarques, les difficultés ou les
suggestions des clients. Et selon le feedback nous faisons l’adaptation et la correction.
15
Puis le scrum master planifie une autre démonstration après quelques jours pour valider
les améliorations.
3.4. Backlog du produit :

Dans cette partie nous intéressons à une partie de la Backlog. Elle est définie par les
clients, le Scrum master, les agents interne de finance, de marketing et de gestion d’affaires.
Le tableau suivant cite les sprints ordonnés selon le critère de priorité. Ce critère est défini par les
clients et notre Scrum master.
Sprint ID User Story Effort

En tant qu’utilisateur je veux ... (Homme/Jour)
1 Ajouter un produit de type Hôtel, Forfait, Transport, Activité

et Location de voiture 3
Gestion des Produits
2 Lister les produits et faire une recherche selon des critères

pertinents 2
3 Modifier les données d’un produit 3

4 Gérer les localités d’un produit 2
5 Gérer les tags d’un produit 2
6 Exporter le résultat de recherche 1
Gestion des Tiers
7 Ajouter un Tiers de type Fournisseur, Client, Producteur et

Apporteur d’affaire 3
8 Lister les tiers et faire une recherche selon des critères

pertinents 2
9 Modifier les données d’un tiers 3

10 Ajouter une localité
Gestion des
3
Localités
11 Lister les localités et faire une recherche selon des critères

pertinents 2
12 Modifier les données d’une localité 3
16
Gestion des Tags Gestion des Paramètres

13 Ajouter un paramètre avec les traductions 3
14 Lister les paramètres et faire une recherche selon des critères

pertinents 2
15 Modifier les paramètres avec les traductions 3
16 Ajouter un ou plusieurs tags à un objet 3

17 Lister les tags dans l’écran de l’objet 2
18 Modifier les tags dans l’écran de l’objet 4
19 Supprimer les tags dans l’écrans de l’objet 2
Gestion des Localités du
20 Ajouter une ou plusieurs localité à un produit 3

21 Lister les localités d’un produit 2
produit
22 Modifier les localités du produit 4
23 Supprimer les localités du produit 2
24 Ajouter un Détail d’un produit 4

Gestion des
25
Détails
Modifier un Détail d’un produit 5

26 Lister les Détails 2
27 Supprimer un Détail avec la possibilité de supprimer ou
consulter un média d’un Détail séparément (photo/vidéo) 4
28
Utilisateurs
Ajouter un utilisateur
Gestion des
3
29 Lister les utilisateurs et faire une recherche selon des critères
pertinents 2
30 Modifier les données de l’utilisateur et les numéros de

téléphone 3
31 Ajouter une catégorie d’un produit 5
Gestion
des
32 Lister les catégories selon l’ordre et je veux réorganiser

l’ordre d’après la liste directement. 3
17
33 Modifier les données d’une catégorie 4

Catégories
des Tarifs
34 Ajouter un tarif d’un produit 5

Gestion Gestion des Gestion des Gestion des Règles Gestion des Documents Gestion
35 Lister les tarifs 2

36 Modifier les données d’un tarif 4
37 Ajouter des répertoires et sous répertoires 3
38 Modifier les répertoires et sous répertoires 2
Électroniques
39 Supprimer les répertoires et sous répertoires 2

40 Consulter les photos des répertoires ou des sous répertoires 3
41 Ajouter des photos dans les répertoires 4
42 Supprimer les photos des répertoires 2
43 Consulter la photo en taille réelle 0.5
4 Ajouter les règles segments d’un forfait 5
41 Lister les règles segments d’un forfait
Segments
3
42 Modifier les règles segments d’un forfait 5
43 Supprimer les règles segments d’un forfait 1

Segments Vols
44 Ajouter les segments d’un vol 3

45 Modifier les segments d’un vol 3
46 Lister les segments d’un vol 2
47 Supprimer les segments d’un vol 1
48 Associer des photos à un objet 3
photos
49 Lister les photos associées à un objet 3

50 Supprimer ou Consulter une photo associées à un objet 2
51 Ajouter les données Search Engine Optimization (SEO) 3
des
52 Lister les données de SEO 2

53 Modifier les données de SEO 2
18
54 Supprimer les données de SEO 1

données
SEO
Gérer mes emails et mes numéros de téléphones avec les

55
Configuration du
2
indicatifs des pays
56
compte
Gérer mes adresses de facturation 2

Gérer mes préférences : Devise(s), Langue(s), Ville(s) de
57 5
départ, Pays de destination, Type(s) de produit
Développement de
58 Lister les utilisateurs 1

l`application mobile
59 Lister les produits : Hôtel, Forfait, Transport et Activité 6

60 Rechercher les produit par nom 3
61 Consulter les détails des produits 5
62 Localiser l’emplacement du produit 6
63 Afficher mes lieux à proximité du produit 6
64
Gestion des Gestion des règles de Gestion des
Ajouter des articles 4

articles
Lister les articles et faire une recherche selon des critères

65 2
pertinents
66 Modifier les articles 3
67 Ajouter des règles de tarification 3
Lister les règles de tarification et faire une recherche selon
tarification
68 1
des critères pertinents
69 Modifier les règles de tarification 2
70 Gérer les produits concernés par la règle de tarification 3
71 Gérer les cible(s) (groupe, canal B2C, B2B) 3
Commandes
72 Ajouter une commande 3

Lister les commandes et faire une recherche selon des critères
73 1
pertinents
74 Modifier une commande 4
19
1.1. Planning des sprints du projet :

Nous présentons dans le planning des sprints du projet d’une façon simplifiée. Nous
avons fait la somme de la durée de conception, de réalisation, de correction et d’amélioration
vers la version 2.
Nous travaillions sur deux sprints en parallèle pour accélérer le rythme de développement
et pour mieux organisé l’équipe. Le planning comporte que les sprints que nous avons réalisés.
Le tableau suivant donne une idée générale sur le plannings d’un partie des sprints réalisés.
Période/Semaine 1 2 3 4
Gestion des Produits Gestion des Localités

Du 01/01 au 31/01
Gestion des Tiers Gestion des Paramètres
Gestion des Tags Gestion des Utilisateurs

Du 01/02 au 29/02 Gestion des
Localités du Gestion des Détails
produit
Gestion des catégories Gestion des Tarifs

Du 01/03 au 31/03
Gestion des
Gestion des Document Électroniques
photos
Gestion des
Du 01/04 au 30/04 Gestion des Règles Segments
photos
Développement de l’application mobile
Du 01/05 au 31/05 Développement de l’application mobile

Gestion des Segments Vols Gestion des données SEO
Du 01/06 au 30/06 Configuration du compte Gestion des règles de tarification
20
Gestion des articles Gestion des Commandes
Conclusion
Nous avons précisé le périmètre du projet par la définition des besoins puis par la
solution adoptée. Après l’alimentation de la Backlog et la mise en place du planning nous
terminerons les préparations pour le projet par l’installation de l’environnement de travail. Ce
sujet sera plus particulièrement étudié dans le chapitre suivant.
21
Chapitre 3 : Environnement de travail
Introduction :
À travers ce chapitre, nous allons décrire l’environnement logiciel en citant les

technologies et les outils utilisés. Ensuite nous allons déterminer l’environnement matériel afin
de réaliser l’application web de Back Office et l’application mobile.
1. Environnement logiciel :
1.1. Présentation de l’environnement logiciel de l’application web :
Notre architecte M. Aniss Boumrigua a défini les technologies à utiliser dans le projet web :
Les langages et les Frameworks utilisés sont:
 PHP 7.4
 Symfony 5
 API Platform : C’est un Framework PHP permettant de créer facilement et de
personnaliser les API.
 MariaDB (MySQL)
 Javascript (jQuery)
 Bootstrap
 Twig : C’est un moteur de modèle pour le langage de programmation PHP.
 Node.js : Utilisé dans le build de Webpack Encore et le chargement des modules de
Node Package Manager (npm).
Les outils utilisés sont :
 Gitlab (versionning)
 Confluence : C’est un outil wiki de collaboration utilisé pour aider les équipes à
collaborer et à partager efficacement leurs connaissances.
 PhpStorm
22
 Postman : C’est est un client API qui facilite la création, le partage d'API pour les
développeurs.
 Fiddler 4 : C’est un proxy de débogage Web qui enregistre tout le trafic HTTP(S).
L’environnement de développement et de production des services, de la back office et les
sites web B2C, B2B sont hébergés sur :
 Platform.sh
La figure suivante donne un aperçu général sur les technologies qui seront utilisées dans le projet
web :
Figure 3.7 : Présentation de la pile technologique
23
1.2. Présentation de l’environnement logiciel de l’application mobile :

Nous avons défini la technologie à utiliser dans le développement de l’application mobile
en fonction des besoins fonctionnels et l’efficacité de la technologie en termes de performance et
du temps de développement.
Nous avons choisi les deux multiplateformes les plus populaires React-native et Flutter et nous
avons fait le choix selon la comparaison suivante :
En termes de performance :
La figure 3.2 montre que Flutter est 3 fois plus performant que React-native selon des
tests de performances intensives de CPU font par des spécialistes de benchmark avec différents
algorithmes.
Figure 3.8 : Comparaison de performance entre React-native et Flutter

En termes du temps de développement :
24
Flutter est basé sur les widgets. Un widget est un composant qui peut être par exemple un
bouton, une liste, un menu...
Nous pouvons également créer nos propre widgets qui peuvent être facilement réutilisés.
En plus le syntaxe est trop facile à comprendre. En plus nous avons déjà découvert ce
Framework dans sa version beta et nous avons développé des applications avec cette technologie.
En 2020 Flutter a dépassé React-native sur les sites tels que Stack Overflow et même sur
GitHub.
C ’ e s t V r a i F l u t
Figure 3.9 : Nombre de question sur Flutter et React-native
2020 mais en 2019 Google a publié la version Stable de Flutter pour mobile qui est prêt pour la
production.
Voilà le choix est fait et nous avons adopté le Framework multiplateforme Flutter et son langage
de programmation Dart.
 Dart :
25
Dart est un langage de programmation, orienté objet et à usage général développé par
Google en 2011. Il est utilisé pour le développement Web côté client et côté serveur. Dart est
également utilisé pour le développement mobile natif et multiplateforme.
 Flutter :
Flutter est un kit de développement logiciel créé par Google. Il est utilisé pour
développer des applications pour Android, iOS, Windows, Mac, Linux, Google Fuchsia et le
web.
Les outils utilisés sont :
 Android Studio
 Adobe Photoshop
2. Environnement Matériel :
Le tableau suivant résume le matériel utilisé pendant le développement de la back Office
et l’application mobile.
Type d’appareil CPU RAM Résolution Système d’exploitation

PC ASUS I5-9400F 8 GO 1366x768 Windows 10
PC ASUS I7-6700HQ 16 GO 1366x768 Windows 10
Smartphone Cortex-A7 1 GO 480x800 Android 7
Evertek
Smartphone Lenovo Cortex-A53 2 GO 720x1280 Android 5.0
Smartphone Huawei Cortex-A53 2 GO 720x1440 Android 8.1
Tablette Versus MTK 8321 1 GO 600x1024 Android 6
Conclusion :
Nous avons cité les différents technologies et outils utilisés dans le projet. Une fois
l’environnement de travail est installé nous suivons le planning et nous commençons les
26
itérations d’affinement et d’adaptation des fonctionnalités afin de livrer des incréments

fonctionnels c’est ce qu'on va voir dans les chapitres qui suivent.
27
Chapitre 4 : Sprints Gestion des Produits
Introduction :
Lors de la première partie de ce chapitre, nous allons donner un aperçu général sur les
modules à réaliser dans le premier release. En effet, chaque release englobe un ensemble de
sprint. Puis nous allons détailler les sprints de gestion des produits passant par la conception et le
raffinement jusqu’à l’étape de réalisation.
1. Conception générale de gestion des produits :

1.1. Diagramme de cas d’utilisation général :
1.2.
Figure 4.10 : Diagramme de cas d'utilisation général
Diagramme de classes général :
28
Le diagramme de classes général ci-dessous donne une idée sur la conception de nos
modules. Pour simplifier cette partie nous avons mis un exemple minimal qui décrit les entités et
ses relations.
Figure 4.11: Diagramme de classes général
1.3. Les micro-services impliqués :

Nous citons dans cette liste tous les micro-services impliqués dans la gestion des produits :
- Service Products : Gérer les produits.

- Service Master Parameter Values : Obtenir les types et les sous types du produit.
- Service Third Party : Obtenir les fournisseurs du tenant.
29
- Service Localities : Obtenir les localités du tenant et les localités par défaut.
- Service Object Tags : Gérer les tags du produit.
- Service Product Localities : Gérer les localités du produit.
1.4. Diagramme de cas d’utilisation raffiné de « Gestion des Produits » :

La figure 4.3 montre un diagramme de cas d’utilisation qui présente un raffinement pour
le cas d’utilisation « Gestion des Produits » :
Figure 4.12 : Diagramme de cas d'utilisation « Gestion des Produits »

2.
Raffinement de cas d’utilisation « Ajouter Produit » :
2.1. Diagramme de séquence système « Ajouter Produit » :
La figure suivante montre le diagramme de séquence système de cas d’utilisation « Ajouter
Produit » :
30
Figure 4.13 : Diagramme de séquence système « Ajouter Produit »

Le Manager présente la partie intermédiaire entre l’utilisateur et les services qui est
responsable sur l’affichage des interfaces, les traitements côté client et l’envoie des requêtes ou
la réception des réponses des services.
Cas n° 1
Nom : Ajouter Produit (package « Gestion des produits »)

Acteur(s) : Utilisateur (appartient à un tenant)
Description : L’ajout d’un produit est une initialisation des données du produit. La pop-up d’ajout
d’un produit comprenne que les informations les plus pertinentes à saisir.
Préconditions : L’utilisateur doit être authentifié à Leisure plateforme (Package « S’authentifier »).
Démarrage : L’utilisateur a ouvert la pop-up Produit dans n’importe quelle page dans la plateforme
Leisure.
 Le scénario nominal
1 - Le système vérifie le token de l’utilisateur connecté.
31
2 - Si le token est valide, le système fait appel aux données pour initialiser la pop-up produit par
les données nécessaires (comme les valeurs des listes).
3 - Le système affiche la pop-up avec les données chargées
4 - L’utilisateur sélectionne le type du produit.
5 - Le système charge les sous-types qui correspondent au type du produit choisi.
6 - L’utilisateur sélectionne le sous-type.
7 - L’utilisateur tape 3 lettres pour avoir des suggestions de localité(s) selon le type de produit.
8 - Le système fait appel à un service de localités minifié et charge la liste par des données selon
les lettres saisies.
9 - L’utilisateur complète la saisie et clique sur le bouton Enregistrer.
10 - Le système valide, enregistre le produit puis ferme la pop-up produit
11 - Le système affiche un message de succès avec l’identifiant du produit inséré.
 Les scénarios alternatifs

4.a L’utilisateur décide de quitter la pop-up Produit.
9.b L’utilisateur complète la saisie et clique sur Enregistrer et Nouveau.
9.c L’utilisateur complète la saisie et clique sur Enregistrer et Continuer.
10.a Le système valide, enregistre le produit puis réinitialise la pop-up.
10.b Le système valide, enregistre le produit puis ouvre l’écran de mise à jour du produit.
2.2. Réalisation de cas d’utilisation « Ajouter Produit » :

Dans cette section, nous présentons la réalisation de l’interface d’ajout d’un produit
comme montre la figure 4.5 ci-dessous.Il est possible d’associé ici au produit sa localisation.
32
Figure 4.14 : Réalisation de cas d’utilisation « Ajouter Produit »
3. Raffinement de cas d’utilisation « Rechercher Produit » :

3.1. Diagramme de séquence système « Rechercher Produit » :
La figure suivante montre le diagramme de séquence système de cas d’utilisation « Rechercher
Produit » :
33
: : :
Figure 4.15 : Diagramme de séquence système « Rechercher Produit »
Cas n° 2
Nom : Rechercher Produit (package « Gestion des produits »)

Description : L’utilisateur peut lancer une recherche avec ou sans de(s) critère(s) de recherche. Pour
ce cas on trouve plusieurs critères qui peuvent être appliqués (Id, Nom, Type, Sous type,
Fournisseur, Actif).
Démarrage : L’utilisateur a ouvert la page Produit à partir du menu latéral.
 Le scénario nominal :
2 - Si le token est valide, le système fait appel aux données depuis les services Third Party et
Master parameter values pour alimenter les listes des critères de recherche.
3 - Le système affiche les champs avec les données chargées.
34
4 - L’utilisateur filtre la recherche par saisie des critères de recherche.
5 – Si le critère Type de produit est saisi, le système charge les sous-types qui correspondent au
type du produit choisi.
6 - L’utilisateur choisi et sélectionne le sous-type du produit.
7 - L’utilisateur tape 3 lettres pour avoir des suggestions de localité(s).
8 - Le système fait appel à un service de localités minifié et charge la liste par des données selon
les lettres saisies.
9 - L’utilisateur complète la saisie des filtres et clique sur le bouton Rechercher.
10 - Le système charge les données à partir du service Product en appliquant les filtres saisis et
retourne une liste de produits.
11 - Le système affiche un tableau contenant le résultat souhaité.
 Les scénarios alternatifs :

2.a Le système redirige l’utilisateur à la page de connexion.
4.a L’utilisateur décide de quitter l’écran de recherche.
10.a Aucune donnée ne correspond aux filtres saisis, le système retourne une liste vide.
11.a Le système affiche le message « Aucune donnée ne correspond à la recherche. »
3.2. Réalisation de cas d’utilisation « Rechercher Produit » :

Nous présentons dans la figure 4.7 ci-dessous l’écran de recherche des produits.
L’utilisateur peut appliquer plusieurs filtres afin de lancer une recherche pertinente aussi il est
possible d’exporter la résultat de recherche.
35
Figure 4.16 : Réalisation de cas d'utilisation « Rechercher Produit »
4. Raffinement de cas d’utilisation « Exporter la liste des Produits » :

4.1. Diagramme de séquence système « Exporter la liste des Produits » :
1.2. 1.1.
Figure 4.17 : Diagramme de séquence système « Exporter la liste des Produits »
36
Cas n° 3
Nom : Exporter la liste des Produits (package « Gestion des produits »)

Description : L’utilisateur peut exporter le résultat de recherche en fichier Excel.
Préconditions : L’utilisateur a lancé une recherche et il a reçu un résultat avec au moins un produit
dans le tableau de recherche.
Démarrage : L’utilisateur clique sur le bouton Exporter.
 Le scénario nominal
2 - Si le token est valide, le système charge les données à partir du service Product en appliquant
les filtres saisis et retourne un fichier Excel.
3 - Le système lance automatiquement le téléchargement du fichier côté client.
5. Raffinement de cas d’utilisation « Modifier Produit » :
37
5.1. Diagramme de séquence système « Modifier Produit » :
Cas n° 4
Nom : Modifier Produit (package « 1.5.

Gestion des produits ») 1.4. 1.3.
Description : L’utilisateur peut modifier les données du produit.
Préconditions : L’utilisateur a lancé une recherche et il a reçu un résultat avec au moins un produit
Démarrage : L’utilisateur clique sur l’identifiant du produit d’après la liste de recherche.
Figure 4.18: Diagramme de séquence système « Modifier Produit »

Le scénario nominal :
2 - Si le token est valide et le produit appartient au tenant connecté, le système fait appel aux
données du produit.
4 - L’utilisateur modifie les données du produit.
5 - Le système valide et enregistre les données en appelant le service Product.
6 - Si la mise à jour est réussie, le système affiche un message de succès.
38
4.a L’utilisateur décide de quitter l’écran de la page de mise à jour du produit.
5.a Données invalides, le système n’enregistre pas les données.
6.a La mise à jour échoue, le système affiche un message d’erreur.
5.2. Réalisation de cas d’utilisation « Modifier Produit » :

Nous exposons dans la figure 4.10 l’écran de modification des données d’un produit. Cet
écran donne un accès aux sous-modules selon le type du produit comme
Catégories/Suppléments, Tarifs, Détails, Règles segments, Segment Vols, Photos, SEO,
Affichage web et Stocks.
L’écran de modification de produit est composé par plusieurs blocs comme Tag(s),
Localité(s), Code Externe(e). Les traitements des blocs tels que la modification, la suppression et
même l’ajout sont tous asynchrone.
Figure 4.19 : Réalisation de cas d’utilisation « Modifier Produit »
Conclusion :
39
En guise de conclusion, nous avons réussi à produire le premier incrément « Gestion des
produits ». L’équipe Impact Player a fait les tests d'assurance qualité et après quelques
corrections et optimisations le module est validé et il est actuellement déployé dans
l’environnement de production.
Le sprint suivant selon le planning sera concernant la gestion des tiers c’est ce qu’on va voir dans
le chapitre suivant.
40
Chapitre 5 : Sprints Gestion des Tiers
Introduction :
Dans ce chapitre, nous allons détailler les sprints de gestion des tiers ainsi que les micro-
services impliqués passant par la conception et le raffinement jusqu’à l’étape de réalisation. Les
tiers peuvent être les producteurs des produits, les fournisseurs, les agents externes ou internes.
1. Cas d’utilisation de gestion des Tiers :

1.1. Diagramme de cas d’utilisation raffiné « Gestion des Tiers » :
La figure 5.1 montre un diagramme de cas d’utilisation qui présente un raffinement pour le cas
d’utilisation « Gestion des Tiers » :
1.2.
Figure 5.20 : Diagramme de cas d'utilisation de « Gestion des Tiers »
Les micro-services impliqués :

Nous citons dans cette liste tous les micro-services impliqués dans la gestion des tiers :
- Service Third Party : Gérer les tiers.

- Service Master Parameter Values : Obtenir les types, les sous types des tiers.
- Service Country Calling Code : Obtenir les indicatifs téléphoniques par pays.
- Service Object Phone : Gérer les numéros de téléphone.
41
2. Raffinement de cas d’utilisation « Ajouter Tiers » :

2.1. Diagramme de séquence système « Ajouter Tiers » :
42

Tiers » :
Cas n° 1
: : :
Nom : Ajouter ti
Acteur(s) : Utili
Description : L’
client (Agence d
Préconditions :
Démarrage : L’u
Leisure.
Figure 5.21 : Diagramme de séquence système « Ajouter Tiers »

Le scénario nominal
2 - Si le token est valide, le système fait appel aux données pour initialiser la pop-up tier par les
données nécessaires (comme les types et les sous types).
4 - L’utilisateur sélectionne le type du tiers.
6 - Le système valide, enregistre le tiers puis ferme la pop-up.
7 - Le système affiche un message de succès avec l’identifiant du tiers inséré.
43
4.a L’utilisateur décide de quitter la pop-up tiers.
6.a Le système valide, enregistre le produit puis réinitialise la pop-up.
6.b Le système valide, enregistre le produit puis ouvre l’écran de mise à jour du produit.
2.2. Réalisation de cas d’utilisation « Ajouter Tiers » :

Dans cette section, nous présentons la réalisation de l’interface d’ajout d’un tiers comme
montre la figure 5.3 ci-dessous.Il est possible d’associer au tiers le numéro de fax ou le numéro
de téléphone, avec l’indicatif de pays.
Figure 5.22 : Réalisation de cas d’utilisation « Ajouter Tiers »
3. Raffinement de cas d’utilisation « Rechercher Tiers » :

3.1. Diagramme de séquence système « Rechercher Tiers » :
La figure suivante montre le diagramme de séquence système de cas d’utilisation « Rechercher
Tiers » :
44
: : :
Figure 5.23 : Diagramme de séquence système « Rechercher Tiers »
Cas n° 2
Nom : Rechercher Tiers (package « Gestion des Tiers »)

ce cas on trouve plusieurs critères qui peuvent être appliqués (Id, Nom, Type, Sous type, Groupe).
Démarrage : L’utilisateur a ouvert la page Tiers à partir du menu latéral.
2 - Si le token est valide, le système fait appel aux données d’après le service Master Parameter
Values pour alimenter les listes des critères de recherche (Type et Sous type).
45
6 - Le système charge les données à partir du service Third Party en appliquant les filtres saisis et
retourne une liste de Tiers.

3.2. Réalisation de cas d’utilisation « Rechercher Tiers » :

Nous présentons dans la figure 5.5 ci-dessous l’écran de recherche des tiers. L’utilisateur
peut appliquer plusieurs filtres afin de lancer une recherche pertinente aussi il est possible
d’exporter la résultat de recherche.
46
Figure 5.24 : Réalisation de cas d’utilisation « Rechercher Tiers »
4. Raffinement de cas d’utilisation « Modifier Tiers » :

4.1. Diagramme de séquence système « Modifier Tiers » :
La figure suivante montre le diagramme de séquence système de cas d’utilisation « Modifier
Tiers » :
47
: : :
Figure 5.25 : Diagramme de séquence système « Modifier Tiers »
Cas n° 3
Nom : Modifier Tiers (package « Gestion des Tiers »)

Description : L’utilisateur peut modifier les données d’un tiers.
Préconditions : L’utilisateur a lancé une recherche et il a reçu un résultat avec au moins un tiers
Démarrage : L’utilisateur clique sur l’identifiant du tiers d’après la liste de recherche.
48
2 - Si le token est valide et le produit appartient au tenant connecté, le système fait appel aux
données du tiers.
4 - L’utilisateur modifie les données du tiers.
5 - Le système valide et enregistre les données en appelant le service Third Party.

4.a L’utilisateur décide de quitter l’écran de la page de mise à jour du tiers.
6.a La mise à jour échoue, le système affiche un message d’erreur.
4.2. Réalisation de cas d’utilisation « Modifier Tiers » :

Nous annonçons dans cette partie la réalisation de l’écran de modification des données de
tiers ainsi que le développement des blocs Adresse de facturation, Tag(s), Code(s) Externe(s),
Email(s), Numéro(s) de téléphone.
Cet écran permet l’utilisateur à accéder aux sous-modules comme Détails et Utilisateurs du tiers.
La figure 5.7 donne un aperçu général sur l’écran de modification de tiers.
49
Figure 5.26 : Réalisation de cas d’utilisation « Modifier Tiers »
Conclusion :
Lors de ce chapitre , nous avons vu le fonctionnement du module « Gestion des Tiers »

par la représentation des diagrammes et le scénario nominal ainsi que la partie réalisation.
Suivons le planning notre priorité sera l’onglet détails de produit c’est ce qu’on va voir dans le
chapitre suivant.
50
Chapitre 6 : Sprints Gestion des Détails
Introduction :
Dans ce chapitre, nous présentons en premier lieu la conception des sprints « Gestion des
Détails » ainsi que les micro-services impliqués. Puis, nous passons à l’étape de réalisation afin
de visualiser les différentes fonctionnalités de cet onglet.
1. Cas d’utilisation de gestion des détails:

1.1. Diagramme de cas d’utilisation raffiné « Gestion des détails » :
d’utilisation « Gestion des détails » :
Figure 6.27: Diagramme de cas d'utilisation de « Gestion des Détails »

Nous citons dans cette liste tous les micro-services impliqués dans la gestion des détails :
51
- Service Object Detail : Gérer les détails.

- Service Amazon S3 : Charger les répertoires et les photos du tenant.
- Service Object Media : Gérer les données des photos.
- Service Product : Consulter les produits.
- Service Tenant parameter values : Obtenir les groupes du tenant.
- Service Third Party : Obtenir les fournisseurs du tenant.
2. Raffinement de cas d’utilisation « Ajouter Détail » :

2.1. Diagramme de séquence système « Ajouter Détail » :
52

Détail » :
: : : : :
Figure 6.28 : Diagramme de séquence système « Ajouter Détail »
 Scénario nominale :
2 - Si le token est valide, le système fait appel aux données pour initialiser la pop-up Détail objet
par les données nécessaires (comme les valeurs des listes).
4 - L’utilisateur sélectionne l’entité.
53
5 - Le système charge les groupes qui correspondent à l’entité choisie.
6 - L’utilisateur sélectionne les photos du détail.
8 - Le système valide, enregistre le détail puis ferme la pop-up Détail objet
9 - Le système affiche un message de succès avec le nombre des photos insérées.

4.a L’utilisateur décide de quitter la pop-up Détail objet.
8.a Le système valide, enregistre le détail puis réinitialise la pop-up.
2.2. Réalisation de cas d’utilisation « Ajouter Détail » :

Dans cette section, nous présentons la réalisation de l’écran d’ajout d’un détail. Une
photo de détail peut être externe ou interne. Il est possible d’ajouter des vidéos en ajoutant le lien
de la vidéo.
54
Pour les photos internes elles doivent être insérées dans des répertoires à l’aide du module de de
gestion des documents électroniques (GED).
Figure 6.29 : Réalisation de cas d’utilisation « Ajouter Détail »
3. Raffinement de cas d’utilisation « Modifier Détail » :

3.1. Diagramme de séquence système « Modifier Détail » :
55

Détail » :
Figure 6.30 : Diagramme de séquence système « Modifier Détail »
Cas n° 2
Nom : Modifier détail (package « Gestion des détails »)

56
Description : L’utilisateur peut modifier les données d’un détail.
Préconditions : L’utilisateur doit être authentifié à Leisure plateforme (Package « S’authentifier ») et

possède au minimum un objet afin de le modifier.
Démarrage : L’utilisateur a ouvert l’onglet Détails.
2 - Si le token est valide, le système fait appel aux données pour afficher l’onglet Détails.
3 - Le système affiche les données des détails avec les photos associées.
4 - L’utilisateur clique sur le bouton Modifier.
5 - Le système charge les groupes qui correspondent au type d’objet et les répertoires des photos.
6 - L’utilisateur sélectionne les données et sélectionne les photos à associer.
7 - L’utilisateur complète la modification et clique sur le bouton Enregistrer.
8 - Le système valide, enregistre le détail puis ferme la pop-up Détail objet.
9- Le système met à jour l’onglet à la suite de la modification.

6.a L’utilisateur complète la modification et clique sur le bouton Enregistrer.
6.b L’utilisateur décide de quitter la pop-up Détail objet.
8.a Le système valide, enregistre le détail puis réinitialise la pop-up.
3.2. Réalisation de cas d’utilisation « Modifier Détail » :

Nous présentons dans la figure 6.5 la réalisation de l’interface de modification des
données de détail. Cette interface permet l’utilisateur d’ajouter ou de supprimer les photos de
détails.
57
Figure 6.31 : Réalisation de cas d’utilisation « Modifier Détail »
4. Raffinement de cas d’utilisation « Supprimer Détail » :

4.1. Diagramme de séquence système « Supprimer Détail » :
58
La figure suivante montre le diagramme de séquence système de cas d’utilisation « Supprimer

Détail » :
Cas n° 3
: :
Nom : Supprimer détail (package « Gestion des détails »)
Description : L’utilisateur peut supprimer les données d’un détail et les photos associées.

possède au minimum un objet afin de le supprimer.
Figure 6.32 : Diagramme de séquence système « Supprimer Détail »
59
2 - Si le token est valide, le système fait appel aux données des détails.
4 - L’utilisateur clique sur le bouton Supprimer.
5 - Si le détail est trouvé, le système supprime ce détail et actualise l’onglet Détails.

4.a L’utilisateur décide de quitter l’onglet Détails.
5.a Le système ne trouve pas le détail, le système affiche un message d’erreur.
4.2. Réalisation de cas d’utilisation « Supprimer Détail » :

Nous exposons dans la figure 6.7 l’onglet Détails et les boutons de suppression qui
permettent la suppression d’un détail ou d’un ou de plusieurs média(s) séparément :
Figure 6.33 : Réalisation des cas d’utilisation Supprimer Détail et Média
60
5. Raffinement de cas d’utilisation « Supprimer Média » :

5.1. Diagramme de séquence système « Supprimer Média » :
Média » :
: :
Figure 6.34 : Diagramme de séquence système « Supprimer Média »
Cas n° 4
Nom : Supprimer Média d’un détail (package « Gestion des détails »)

Description : L’utilisateur peut supprimer les médias en gardant les données du détail. Les médias
peuvent être des photos ou des vidéos.

possède au minimum un objet avec des médias associés afin de le(s) supprimer.
61
2 - Si le token est valide, le système fait appel aux données des détails.
4 - L’utilisateur clique sur le bouton Supprimer qui se trouve sous chaque média.
5 - Si le média est trouvé, le système supprime ce média et actualise l’onglet Détails.

4.a L’utilisateur décide de quitter l’onglet Détails.
5.a Le système ne trouve pas le média, le système affiche un message d’erreur.
Conclusion :
En conclusion , nous avons détaillé les différentes fonctionnalités de l’onglet Détails par
la présentation des diagrammes de séquences ,les scénarios nominal et alternatif ainsi que la
partie réalisation. L’utilisateur maintenant peut énumérer les détails d’un produit.
Le prochain sprint sera concernant l’onglet Catégories du module Produit c’est ce qu’on va voir
dans le chapitre suivant.
62
Chapitre 7 : Sprints Gestion des Catégories
Chapitre 1: Sprints Gestion des Catégories
Introduction :
À travers ce chapitre, nous annonçons le développement de l’onglet Catégories par le

diagramme de cas d’utilisation raffiné. Nous définissons ensuite les micro-services nécessaires
ainsi que les diagrammes séquences système. Enfin nous présentons la phase de réalisation.
1. Cas d’utilisation de gestion des Catégories :

1.1. Diagramme de cas d’utilisation raffiné « Gestion des Catégories » :
d’utilisation « Gestion des Catégories » :
Figure 7.35 : Diagramme de cas d’utilisation « Gestion des Catégories »
63

Nous citons dans cette liste tous les micro-services impliqués dans la gestion des tiers :
- Service Master Parameter Values : Obtenir les types, les sous types des tiers.
- Service Product Category : Gérer les catégories des produits
2. Raffinement de cas d’utilisation « Ajouter Catégorie » :

2.1. Diagramme de séquence système « Ajouter Catégorie » :
Catégorie/Supplément » :
: : :
Figure 7.36 : Diagramme de séquence système « Ajouter Catégorie »
Cas n° 1
Nom : Ajouter catégorie (package « Gestion des catégories »)

Description : L’utilisateur ajoute une catégorie d’un produit. L’utilisateur doit définir les
catégories/Suppléments du produit pour gérer les tarifs.
64
Préconditions : L’utilisateur doit être authentifié à Leisure plateforme (Package « S’authentifier »)

Démarrage : L’utilisateur a ouvert l’onglet Catégorie dans le module produit.
2 - Si le token est valide, le système fait appel aux données pour initialiser la pop-up catégorie
par les données nécessaires (comme les types et les sous types).
3 - Le système affiche la pop-up avec les données chargées.
5 - Le système valide, enregistre la catégorie puis ferme la pop-up.
6 - Le système affiche un message de succès avec l’identifiant de la catégorie insérée.

4.a L’utilisateur décide de quitter la pop-up catégorie.
6.a Le système valide, enregistre la catégorie puis réinitialise la pop-up.
2.2. Réalisation de cas d’utilisation « Ajouter Catégorie » :

Dans cette partie nous annonçons la réalisation de l’écran Catégorie.Lorsque le produit
est de type Forfait le module Catégorie est renommé en Supplément.Cet écran permet
l’utilisateur d’ajouter les catégories/suppléments d’un produit.
65
Figure 7.37 : Réalisation de cas d’utilisation « Ajouter Catégorie »
3. Raffinement de cas d’utilisation « Lister Catégorie » :

3.1. Diagramme de séquence système « Lister Catégories » :
La figure suivante montre le diagramme de séquence système de cas d’utilisation « Lister
Catégories » :
66
: :
Figure 7.38 : Diagramme de séquence système « Lister les Catégories »
Cas n° 2
Nom : Lister catégories (package « Gestion des Catégories »)

Description : Cet onglet liste les Catégories/Suppléments du produit.
Préconditions : L’utilisateur doit avoir des Catégories/Suppléments pour avoir une liste.
Démarrage : L’utilisateur a ouvert l’onglet Catégories/Suppléments qui se trouve dans le module
produit.
2 - Si le token est valide, le système fait appel aux données pour Charger la liste des catégories.
3 - Le système affiche la liste des catégories sous forme d’un tableau.
4 - L’utilisateur réorganise l’ordre des catégories par un Drag & Drop.
67
5 - Le système faire la mise à jour et affiche un message de succès.
3.2. Réalisation de cas d’utilisation « Lister Catégories » :

La figure 7.5 montre la liste des catégories/suppléments d’un produit. L’utilisateur peut
modifier l’ordre avec un simple Drag & Drop des lignes de la liste afin de réorganiser
l’apparition des catégories/suppléments.
Cet écran permet l’utilisateur aussi de supprimer une catégorie en cliquant sur le bouton
avec l’icône poubelle en rouge ou accéder à l’écran de modification en mode asynchrone en
cliquant sur le bouton avec l’icône stylo en vert.
Figure 7.39 : Réalisation de cas d’utilisation « Lister Catégories »
4. Raffinement de cas d’utilisation « Modifier Catégorie » :

4.1. Diagramme de séquence système « Modifier Catégories » :
Catégorie » :
68
: : :
Figure 7.40 : Diagramme de séquence système « Modifier Catégories »
Cas n° 3
Nom : Modifier Catégorie (package « Gestion des Catégories »)

Description : L’utilisateur peut modifier les catégories d’un produit.
Préconditions : L’utilisateur a ouvert l’onglet Catégories/Suppléments.
Démarrage : L’utilisateur clique sur le bouton Modifier.
2 - Si le token est valide, le système fait appel aux données.
69
4 - L’utilisateur modifie les données de la catégories.
5 - Le système valide et enregistre les données en appelant le service Product Category.

4.a L’utilisateur décide de quitter la pop-up de mise à jour de catégorie.
4.2. Réalisation de cas d’utilisation « Modifier Catégorie » :

Dans cette section nous exposons dans la figure 7.7 la réalisation de l’écran de
modification des données d’une catégorie :
Figure 7.41 : Réalisation de cas d’utilisation « Modifier Catégorie »
5. Raffinement de cas d’utilisation « Supprimer Catégorie » :

5.1. Diagramme de séquence système « Supprimer Catégorie » :
Catégorie » :
70
: :
Figure 7.42 : Diagramme de séquence système « Supprimer Catégorie »
Cas n° 4
Nom : Supprimer Catégorie (package « Gestion des Catégories »)

Description : L’utilisateur peut supprimer les Catégories/Suppléments.

possède au minimum une catégorie insérée.
Démarrage : L’utilisateur a ouvert l’onglet Catégories/Suppléments.
Conclusion :
Pour conclure, nous venons de présenter le développement de l’onglet catégories passant

de la conception jusqu’à la réalisation. Cet onglet est la première étape afin de préparer pour le
sprint « Gestion des Tarifs » c'est qu'on va découvrir dans le chapitre qui suit.
71
72
Chapitre 8 : Sprints Gestion des Tarifs
Introduction :
Dans ce chapitre, nous allons détailler les sprints de gestion des tarifs ainsi que les micro-
services impliqués passant par la conception et le raffinement jusqu’à l’étape de réalisation.
1. Cas d’utilisation de gestion des Tarifs :

1.1. Diagramme de cas d’utilisation raffiné « Gestion des Tarifs » :
d’utilisation « Gestion des Tarifs » :
Figure 8.43 : Diagramme de cas d’utilisation « Gestion des Tarifs »
73

Nous citons dans cette liste tous les micro-services impliqués dans la gestion des tarifs :
- Service Fare : Gérer les tarifs.

- Service Fare Types : Obtenir les types des tarifs.
- Service Product Category : Obtenir les catégories du produit.
- Service Master Parameter Values : Obtenir les types d’occupation.
2. Raffinement de cas d’utilisation « Ajouter Tarifs » :

2.1. Diagramme de séquence système « Ajouter Tarifs » :
La figure 8.2 montre le diagramme de séquence système de cas d’utilisation « Ajouter Tarifs » :
: : :
Figure 8.44 : Diagramme de séquence système « Ajouter Tarif »
Cas n° 1
Nom : Ajouter Tarif (package « Gestion des Tarifs »)
74

Description : L’utilisateur ajoute le tarif à une catégorie d’un produit. L’utilisateur doit définir les
catégories/Suppléments du produit pour gérer les tarifs.
Préconditions : L’utilisateur doit avoir au moins une catégories/Suppléments associée au produit afin
de gérer les tarifs.
Démarrage : L’utilisateur a ouvert l’onglet Tarifs dans le module produit.
2 - Si le token est valide, le système fait appel aux données pour initialiser la pop-up Tarif
produit par les données nécessaires (comme les catégories, les types d’occupation, les devises...).
5 - Le système valide, enregistre le tarif puis ferme la pop-up.
6 - Le système affiche un message de succès avec l’identifiant du tarif inséré.

4.a L’utilisateur décide de quitter la pop-up Tarif produit.
6.a Le système valide, enregistre le tarif puis réinitialise la pop-up.
2.2. Réalisation de cas d’utilisation « Ajouter Tarif » :

Nous présentons la figure 8.3 la réalisation de l’écran d’ajout d’un tarif. Chaque tarif
cible une catégorie/supplément de ce produit et pas le produit directement.
75
Figure 8.45 : Réalisation de cas d’utilisation « Ajouter Tarif »
3. Raffinement de cas d’utilisation « Lister Tarifs » :

3.1. Diagramme de séquence système « Lister Tarifs » :
76
La figure suivante montre le diagramme de séquence système de cas d’utilisation « Lister

Tarifs » :
Cas n° 2
: :
Nom : Lister tarifs (package « Gestion des Tarifs »)
Description : Cet onglet liste les Tarifs du produit.
Préconditions : L’utilisateur doit avoir un tarif inséré pour avoir une liste de tarifs.
Démarrage : L’utilisateur a ouvert l’onglet Tarifs qui se trouve dans le module produit.
Figure 8.46 : Diagramme de séquence système « Lister Tarifs »
2 - Si le token est valide, le système fait appel aux données pour Charger la liste des tarifs.
3 - Le système affiche la liste des tarifs sous forme d’un tableau.
4 - Le système faire la mise à jour et affiche un message de succès.
3.2. Réalisation de cas d’utilisation « Lister Tarifs » :

La figure 8.5 montre la réalisation de l’écran qui liste les différents tarifs d’un produit.
L’utilisateur peut supprimer le tarif via le bouton avec l’icône poubelle en rouge.
77
Figure 8.47 : Réalisation de cas d’utilisation « Lister Tarifs »
4. Raffinement de cas d’utilisation « Modifier Tarif » :

4.1. Diagramme de séquence système « Modifier Tarif » :
78
La figure 8.6 montre le diagramme de séquence système de cas d’utilisation « Modifier Tarifs » :
: : : Cas n° 3
Nom : Modifier
Acteur(s) : Util
Description : L
Préconditions
Démarrage : L
Figure 8.48: Diagramme de séquence système « Modifier Tarif »
79
2 - Si le token est valide, le système fait appel aux données.
4 - L’utilisateur modifie les données du tarif.
5 - Le système valide et enregistre les données en appelant le service Product Fare.

4.a L’utilisateur décide de quitter la pop-up de mise à jour Tarif produit.
4.2. Réalisation de cas d’utilisation « Modifier Tarif » :

Nous exposons dans la figure 8.7 la réalisation de l’écran de modification des données de tarif.
80
Figure 8.49 : Réalisation de cas d’utilisation « Modifier Tarif »
5. Raffinement de cas d’utilisation « Supprimer Tarif » :

5.1. Diagramme de séquence système « Supprimer Tarif » :
La figure 8.8 est un aperçu sur le diagramme de séquence système « Supprimer Tarifs » :
: :
Cas n° 4 Figure 8.50 : Diagramme de séquence système « Supprimer Tarif »
Nom : Supprimer Tarifs (package « Gestion des Tarifs »)

81
Description : L’utilisateur peut supprimer les Tarifs.

possède au minimum un tarif inséré.
Démarrage : L’utilisateur a ouvert l’onglet Tarifs.
Conclusion :
Lors de ce chapitre , nous avons vu le fonctionnement du module « Gestion des Tarifs »

par la représentation des diagrammes et le scénario nominal ainsi que la partie réalisation.
Après la saisie des tarifs d’un produit il est le temps de commencer le développement du module
commande c’est ce qu’on va voir dans le chapitre suivant.
82
Chapitre 9 : Sprints Gestion des Commandes
Introduction :
Dans ce chapitre, nous présentons au premier lieu la conception des sprints « Gestion des
Commandes » ainsi que les micro-services impliqués. Puis, nous passons à l’étape de réalisation
afin de visualiser les différentes fonctionnalités de ce module.
1. Cas d’utilisation « Gestion des Commandes » :

1.1. Diagramme de cas d’utilisation raffiné de « Gestion des Commandes » :
d’utilisation Gestion des commandes :
Figure 9.51 : Diagramme de cas d'utilisation « Gestion des Commandes »
83

Nous citons dans cette liste tous les micro-services :
- Service Master Parameter : Récupérer les civilités, les langues, les statuts des payement
et de réservation.
- Service Order : Gérer les commandes.
- Service Third Party : Créer et récupérer les clients.
- Service Tenant Preference : Récupérer la devise et la langue par défaut
- Service Currency : Récupérer les devises.
- Service User : Récupérer les agent internes.
- Service Product : Récupérer les produits.
2. Raffinement de cas d’utilisation « Ajouter Commande » :

2.1. Diagramme de séquence système « Ajouter Commande » :
Commande » :
: : : :
84
Figure 9.52 : Diagramme de séquence système « Ajouter commande »
Cas n° 1
Nom : Ajouter Commande (package « Gestion des Commandes »)

Description : L’ajout d’une commande d’un client. Cette pop-up permet l’utilisateur aussi de créer
un nouveau client s’il n’est pas existant.
Démarrage : L’utilisateur a ouvert la pop-up Commande dans n’importe quelle page dans la
plateforme Leisure.
2 - Si le token est valide, le système fait appel aux données pour initialiser la pop-up Commande.
Par les données nécessaires comme les champs : Canal, Statut, Civilité, Devise.
4 - L’utilisateur sélectionne Client existant.
5 - L’utilisateur complète la saisie des informations.
6 – L’utilisateur clique sur le bouton Enregistrer.
7 - Le système valide, enregistre la commande puis ferme la pop-up Commande.
85
8 - Le système affiche un message de succès avec l’identifiant du Commande insérée.

4.a L’utilisateur décide de quitter la pop-up Commande.
4.b L’utilisateur sélectionne Nouveau client.
5.a L’utilisateur créer le nouveau client et complète la saisie des informations.
6.a L’utilisateur clique sur le bouton Enregistrer et nouveau.
7.a Le système valide, enregistre la commande puis réinitialise la pop-up.
7.b Le système valide, enregistre le nouveau client et la commande puis ferme la pop-up.
7.c Le système valide, enregistre le nouveau client et la commande puis réinitialise la pop-up.
2.2. Réalisation de cas d’utilisation « Ajouter Commande » :

Dans Cette partie nous exposons la réalisation de l’écran d’ajout de commande. Une
commande doit être assigné à un client d’où si le client est inexistant. L’écrans permet de crée un
nouveau client dans le même endroit sans perte du temps.
L’écrans contient que les données les plus pertinents de la commande Pour ajouter d’autres
produits à la commande il y a un sous module que nous avons développé mais il n’est mis dans
le rapport pour simplifier les choses.
86
Figure 9.53 : Réalisation de cas d’utilisation « Ajouter Commande »
3. Raffinement de cas d’utilisation « Rechercher Commande » :

3.1. Diagramme de séquence système « Rechercher Commande » :
87

Commande » :
: : :
Ca
s
n°
2
No
m :
Rec
her
che
r
Pro
Figure 9.54 : Diagramme de séquence système « Rechercher Commande »
duit
(pa
cka
ge
«
Ges
tion
des
pro
duit
s »)
Act
eur
(s) :
Util
isat
eur
88
(appartient à un tenant)
ce cas on trouve plusieurs critères qui peuvent être appliqués (Id, Nom, Type, Sous type,
Fournisseur, Actif).
Démarrage : L’utilisateur a ouvert la page Produit à partir du menu latéral.
2 - Si le token est valide, le système fait appel aux données d’après les services Third Party et
Master parameter values pour alimenter les listes des critères de recherche.
6 - Le système charge les données à partir du service Order en appliquant les filtres saisis et
retourne une liste des commandes.

3.2. Réalisation de cas d’utilisation « Rechercher Commande » :
89
Nous présentons dans la figure 9.5 ci-dessous l’écran de recherche des commandes.
L’utilisateur peut appliquer plusieurs filtres afin de lancer une recherche pertinente.
L’utilisateur peut accéder à l’écran de modification des données de la commande en cliquant sur
l’identifiant de la commande.
Figure 9.55 : Réalisation de cas d’utilisation « Rechercher Commande »
4. Raffinement de cas d’utilisation « Modifier Commande » :

4.1. Diagramme de séquence système « Modifier Commande »
90
La figure 9.6 montre le diagramme de séquence système de cas d’utilisation « Modifier

Commande » :
Cas n° 3
: : :
Nom : Modifier Commande (package « Gestion des Commandes »)
Description : L’utilisateur peut modifier les données de la commande.
Préconditions : L’utilisateur a lancé une recherche et il a reçu un résultat avec au moins une
commande dans le tableau de recherche.
Démarrage : L’utilisateur clique sur l’identifiant de commande d’après la liste de recherche.
Figure 9.56: Diagramme de séquence système « Modifier Commande »
2 - Si le token est valide et la commande appartient au tenant connecté, le système fait appel aux
données de la commande.
4 - L’utilisateur modifie les données de la commande.
5 - Le système valide et enregistre les données en appelant le service Order.
91
4.a L’utilisateur décide de quitter l’écran de la page de mise à jour.
6.a La mise à jour échouée, le système affiche un message d’erreur.
4.2. Réalisation de cas d’utilisation « Modifier Commande » :

Nous annonçons dans cette partie la réalisation de l’écran de modification des données de
commande. Cet écran permet l’utilisateur d’accéder à l’onglet Prestation qui permet d’ajouter
autres catégories d’un produit.
La figure 9.7 donne un aperçu général sur l’écran de modification des données de la commande :
Figure 9.57 : Réalisation de cas d’utilisation « Modifier Commande »
Conclusion :
En conclusion , nous avons détaillé quelques fonctionnalités du module « Gestion des

Commandes » par la présentation des diagrammes de séquences ,les scénarios nominal et
alternatif ainsi que la partie réalisation.
92
Le prochain sprint sera un peu différent des autres sprints car nous allons entamer le
développement de l’application mobile c'est qu'on va découvrir dans le chapitre qui suit.
93
Chapitre 10 : Sprints Application Mobile
Introduction :
Lors de ce chapitre nous allons illustrer la partie mobile de notre projet. Au premier lieu
nous présentons l’architecture globale et l’architecture de l’application afin de déployer une
application efficace. En deuxième lieu nous montrerons la partie réalisation et tests.
1. Présentation de l’architecture globale de l’application mobile :

La figure suivante présente l’architecture globale de l’application mobile :
Figure 10.58 : Architecture globale de l’application mobile

L’application mobile pointe sur plusieurs services tels que :
94
 Leisure Platform API :

Ce Service est différent de celui qui pointe au Back office. Il est destiné aux applications
Front tels que les applications (B2C, B2B, Mobile). Il fournit plusieurs données formatées,
moins complexes afin de faciliter le traitement côté Front Applications.
Cette API est utile pour notre application mobile afin de mettre en place les interfaces de
recherche et de consultation des détails des produits.
 Mapbox API :
Cette API est utile afin de visualiser la carte géographique et localiser le lieu du produit
sur la carte.
 Here Places API :

Here Places API est utile pour afficher les lieux à proximité du produits tels que (les
restaurants, les banques, les stations, les hôpitales...).
 Google Sheets API :

Puisque le service Leisure Platform n’est pas encore stable. Nous avons utilisé le service
Google Sheets afin de définir les images panoramiques et leurs titres dynamiquement dans la
page d’accueil en mode en ligne.
2. Présentation de l’architecture adoptée :

Selon les besoins fonctionnels de l’application mobile et l’architecture recommandée par
Flutter (BLoC pattern architecture) nous avons défini notre propre architecture qui s’échelonne
sur 4 couches comme montre la figure suivante :
Figure 10.59 : Présentation des couches de l'architecture adoptée

La couche Model est utilisée afin de structurer les données récupérées de la part des
services. Ceci facilite les traitements et le stockage dans le cache.
95
La couche Networking assure la communication de l’application avec les différents

services. Les données récupérées de la part des services sont utilisées afin d’alimenter la couche
Model.
La couche Repository contient les différents traitements tel que les méthodes de
recherche des produits, consultation des détails, récupération des lieux à proximité.
La couche View Contient les widgets qui composent les interfaces affichées. Cette
couche assure les échanges et les interactions de l’utilisateur.
3. Réalisation et tests :
3.1. Navigation entre les interfaces de l’application mobile :
Figure 10.60 : Schéma de navigation entre les interfaces de l’application mobile
3.2. Les interfaces de l’application mobile :

Dans cette partie nous présentons quelques interfaces de l’application mobile afin de
visualiser la réalisation des besoins fonctionnels.
96
 Catalogue et recherche des produits :
Figure 10.61 : Interfaces de catalogue et de recherche des produits
Cette
interface est accessible en mode horizontale avec un autre style d’affichage afin de simplifier la
navigation et l’expérience de l’utilisateur comme montre la figure suivante :
Figure 10.62 : Interface de catalogue des produits en mode horizontale
97
 Afficher les détails d’un produit :
Figure 10.63 : Interfaces de détails d'un produit
98
 Affichage de la localisation du produit et les lieux à proximité:
Figure 10.64 : interfaces d’affichage de la localisation et les lieux à proximité d’un produit
99
 Réalisation des interfaces de paramétrage :
3.3.
Figure 10.65 : Réalisation des interfaces de paramétrage
Les tests unitaires et les tests de widgets :

La figure 10.9 et 10.10 montrent la réussite des tests unitaires et les tests de widget
respectivement.
Ces tests ont permis de tester automatiquement les traitements qui se trouvent dans la
couche repository ainsi que les tests de widgets afin de tester le fonctionnement de l’interface de
l’utilisateur.
Figure 10.66 : Résultat d’exécution des tests unitaires
Figure 10.67 : Résultat d'exécution des tests widgets
Conclusion :
100
Nous avons vu l’architecture de l’application ainsi que les fonctionnalités les plus
prioritaires. Cette application mobile est complémentaire au sites web front. Elle fournit aux
clients finaux un accès aux catalogues afin de découvrir les produits de notre tenant d’une façon
claire et rapide.
101
Conclusion Générale
Notre Projet de fin d’études effectué au sein de l’entreprise Easy Soft a abouti à une
réécriture complète de la solution qui est destinée aux acteurs impliqués de la chaîne touristique
et dans le domaine d’e-tourisme en général. Nous avons commencé par l’étude de la nouvelle
architecture qui est basée sur les micro-services en utilisant lors de développement des
technologies open source. Cette architecture est conçue par notre expert.
Ensuite, nous étions responsables sur la réalisation d’une plateforme de Back office et
d’une application mobile, en même temps nous avons eu d’autres responsabilités telles que le
support techniques des développeurs, la mise en place des règles techniques et ergonomiques, la
résolution des points d’architecture, la rédaction de la documentation, la formation d’intégration
des nouveaux développeurs stagiaires.
Nous avons pu résoudre plus de 800 points remontés avec plus de 1300 contributions.
Durant les 7 derniers mois nous avons réalisé une tranche de 33% de la totalité du travail sur
différentes plateformes qui inclut 16 autres développeurs active.
À présent, les 20 sprints que nous avons réalisés répondent pratiquement aux objectifs
énoncés au niveau de la Backlog et le client utilise déjà ses modules en mode production.
En plus, nous avons développé une application mobile en utilisant une technologie
moderne qui a apparu en 2019.À travers cette application nous pensions que nous avons fait un
travail complet qui réunit le développement d’un projet web et mobile.
La passion, la persistance et l’expérience sont suffisantes afin d’acquérir les

connaissances et les compétences nécessaires.
Faute de temps, nous n’avons pas commencé la version 3 des modules. Nous allons
continuer avec l’équipe dans les mois qui suivent afin de déployer autres incréments qui
comportent des traitements plus avancés de calcul et des fonctionnalités plus complexes ainsi
que le système de cache, le système de log et plein d’autres choses qui nous aident à bien
préparer les enjeux futurs.
102
Webographie
[1] https://symfony.com/doc/current/index.html , consulté le 17 Décembre 2019.
[2] https://www.w3schools.com , consulté le 20 Décembre 2019.
[3] https://jquery.com , consulté le 24 Décembre 2019.
[4] https://getcomposer.org , consulté le 05 Janvier 2020.
[5] https://git-scm.com/doc , consulté le 08 Janvier 2020.
[6] https://api-platform.com , consulté le 12 Janvier 2020.
[7] https://stackoverflow.com , consulté le 19 Janvier 2020.
[8] https://github.com , consulté le 15 Février 2020.
[9] https://docs.npmjs.com , consulté le 28 Février 2020.
[10] https://www.php.net , consulté le 07 Mars 2020.
[11] https://flutter.dev/docs , consulté le 18 Avril 2020.
[12] https://pub.dev , consulté le 04 Mai 2020.
[13] https://www.advences.com , consulté le 18 Mai 2020.
[14] https://platform.sh , consulté le 21 Mai 2020.
‫تلخيص‬
‫يلخص هذا التقرير العمل المنجز في إطار مشروع نهاية الدراسات للحصول على دبلوم الترخيص التطبيقي في تكنولوجيا المعلومات‬
‫ضمن شركة إيزي سوفت‬.
‫يتمثل العمل في إنشاء منصة مكتب خلفي وتطبيقة محمولة للسياحة اإللكترونية مخصصة للجهات الفاعلة في السلسلة السياحية على أساس‬
‫ بنية الخدمات الدقيقة باإلضافة إلى إيجاد بدائل لبعض التقنيات التي عرضت حدودها‬.
‫ ويب باك أٌونكور‬،‫ فالتّر‬،‫ أ بي إي بالت فورم‬،‫ سكروم‬،‫سيرفيس‬-‫ ميكرو‬،5 ‫ سامفوني‬،‫ السياحة اإللكترونية‬:‫الكلمات المفاتيح‬.
Résumé
Le présent rapport synthétise le travail effectué dans le cadre du projet de fin d’études pour
l’obtention du diplôme de Licence Appliquée en Technologies de l'Informatique au sein de
l’entreprise Easy Soft.
Le travail consiste à réaliser une plateforme Back office et une application mobile e-tourisme
destinée aux acteurs de la chaîne touristique en se basant sur une architecture micro-services
ainsi que de trouver des alternatives pour quelques technologies qui ont présenté leurs limites.
Mots clés: E-tourisme, Symfony 5, Micro-services, Scrum, API-Platform, Flutter, Web pack
Encore.
Abstract
This report summarizes the work carried out within the framework of the end of studies project
to obtain the diploma of Applied License in Information Technology within the company Easy
Soft.
The work consists in creating a Back office platform and a mobile e-tourism application intended
for actors in the tourist chain based on a micro-services architecture as well as finding
alternatives for some technologies which have presented their limits.
Keywords: E-tourism, Symfony 5, Micro-services, Scrum, API-Platform, Flutter, Web pack

Encore.

Rapport PFE v1.0

Transféré par

Droits d'auteur :

Formats disponibles

Rapport PFE v1.0

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport PFE v1.0

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’enseignement supérieur et de la recherche scientifique

Direction Générale des Études Technologiques

RAPPORT DE STAGE DE FIN D'ETUDES

Licence Appliquée en Technologies de l'Informatique

Réalisation d'une plateforme Back office et une

Farouk Ben Abed

Développement des Systèmes d'Information

Année Universitaire : 2019/2020

Année Universitaire : 2019/2020

À mon cher oncle Lassaad et à toute ma famille Paternelle et

Maternelle, que Dieu les protège et leur donne une longue et

À Wassim et Yassine et à tous mes amis qui m'ont soutenu et encouragé.

Ben Abed Farouk

Nous tenons à remercier chaleureusement Advences et spécialement le manager de la société

Nous tenons également à remercier notre enseignant et encadreur pédagogique, M. Aymen

Ce rapport s’échelonnera sur 10 chapitres comme suit :

Chapitre 1: Présentation générale et Cadre du

1. Présentation de l’organisme d’accueil :

1.2. L’organigramme de la société générale :

3 1.1: Organigramme de la société générale Advences

1.3. Présentation de l’entreprise Easy Soft :

1.4. L’organigramme de l’entreprise Easy Soft :

Figure 1.2: Organigramme de l'entreprise Easy Soft

C’est un système d’information e-tourisme qui permet au client de gagner du temps et

2.2. Objectifs du stage :

Après la présentation de l’organisme d’accueil et la définition du cadre de projet nous

Chapitre 1 : Analyse et Spécification des besoins

1. Analyse et proposition de la solution :

Figure 2.3 : Les fonctionnalités

Le système d’information permet aux clients de :

À partir d’une version standard disponible :

Techniquement ce système d’information est développé en Coldfusion comme langage backend.

1.2. Critique de l’existant :

La plateforme est conçue comme un bloc contenant plusieurs fonctionnalités. Cela

1.3. Solution proposée :

Figure 2.4 : Schéma de l'architecture globale de la solution proposée

Les plateformes logicielles sont :

2. Spécification des besoins :

 Catalogue pour chaque type de produit : Le catalogue permet à l’utilisateur de

2.2. Besoins non fonctionnels :

 Temps de réponse : Utilisation des services minifiés afin d’optimiser le temps

 Présence des tests unitaires et tests widgets

3.1. Méthode adoptée

Après l’analyse du périmètre et les spécificités du projet, l’équipe de développement a

3.2. Les rôles et les responsabilités de chaque personne :

 Coordinateur entre les équipes de développement et les clients.

Teams : Nous sommes 25 personnes qui forment 5 équipes comme suit :

 Équipe Applications Front (CF Travel)

 Équipe Service Desk

Parmi les rôles que nous avons eu pendant notre stage :

3.3. Règles interne de communication :

Figure 2.5 : Exemple d’une feuille de suivi

 Une tâche de développement ou de documentation

Figure 2.6 : Exemple d'un bilan de la semaine

3.4. Backlog du produit :

Sprint ID User Story Effort

1 Ajouter un produit de type Hôtel, Forfait, Transport, Activité

2 Lister les produits et faire une recherche selon des critères

3 Modifier les données d’un produit 3

7 Ajouter un Tiers de type Fournisseur, Client, Producteur et