Ce document présente un stage de fin d'études portant sur la conception et le développement d'une application de gestion des réclamations client, effectué par Ouertatani Mohamed Ayoub et Mselmi Marwen à Arabsoft. Il aborde l'analyse des besoins, la conception, et les solutions proposées pour automatiser le traitement des réclamations, mettant en lumière les lacunes du système existant. Le projet conclut avec des perspectives d'amélioration, notamment le développement d'une application mobile.

1. Ministère de l’Enseignement Supérieur
Université de Carthage
Ecole Supérieure de Technologie et
d’Informatique
Stage de fin d’études
présenté pour obtenir le
Diplôme de Licence Appliquée en Informatique
Conception et développement d’une
application de
Gestion des Réclamations et Interventions Clients
Réalisé par :
- Ouertatani Mohamed Ayoub
- Mselmi Marwen
Encadré par :
- Mme Lamouchi Olfa (ESTI)
- Ayari Kilani (ArabSoft)

2. PLAN
I. Introduction
II. Analyse des besoins
III. Conception
IV. Réalisation
V. Conclusion et perspective
2/22

3. I. INTRODUCTION
3/22
1. Organisme d’accueil
ArabSoft est l'une des plus importantes sociétés de
développement informatique en Tunisie. S'appuyant sur une
force de production et de vente de logiciels et d’applications.
 Fondée depuis 1985
 Capital social : 500.000 DT

4. 2. Description de l’existant
Si un client désire formuler une réclamation concernant un
produit logiciel ou matériel, il doit se déplacer pour rencontrer
l’agent du support technique de la société ou envoyer un e-mail
à l’équipe.
Alors un des agents saisit manuellement une fiche
d’intervention et la passe à l’ingénieur support.
4/22

5. 3. Problématique
 Absence d’un support automatisé pour le traitement des
réclamations logicielles et matérielles des clients
 Absence de suivi : l’état de la réclamation n’est pas connu à
un moment donné.
 Manque de la sécurité dans le service client : risque de perte
de données telles que les feuilles des contrats et les fiches
d’informations.
 Absence d’historisation : on ne peut pas déterminer les
solutions aux problèmes les plus fréquemment rencontrés.
 La dépendance entre les tâches pose une lourdeur de travail
qui génère une perte de temps énorme. 5/22

6. 4. Solutions
L’idéal serait d’avoir une application web qui permet de :
 Informatiser la gestion des réclamations et des interventions
clients
 Accès aux contrats des clients.
 Séparer les problèmes logiciels aux problèmes matériels.
 La consultation et le suivi des réclamations.
6/22

7. 5. Méthodologie adoptée
7/22
Méthode Points forts Points faibles
RUP
Rational Unified
Process
- Itératif
- Spécifie le dialogue
entre les différents intervenants
du projet : les livrables, les
plannings, les prototypes…
- Propose des modèles de
documents, et des canevas pour
des projets types
- Coûteux à personnaliser
- Très axé processus, au
détriment du
développement : peu de
place pour le code et la
technologie
XP
eXtreme
Programming
- Itératif
- Simple à mettre en œuvre
- Fait une large place aux
aspects techniques :
prototypes, règles de
développement, tests…
- Ne couvre pas les
phases en amont et en aval au
développement
- Elude la phase d'analyse, si bien
qu'on peut dépenser son énergie à
faire et défaire
- Assez flou dans sa mise en œuvre
2TUP
Two Track
Unified
Process
-Itératif Fait un large place à la
technologie et à la gestion du
risque
-Définit les profils des
intervenants, les livrables, les
plannings, les prototypes
-Plutôt superficiel sur les phases
situées en amont et en aval du
développement : capture des
besoins, support, maintenance,
gestion du changement…
-Ne propose pas de documents
types

8. II. ANALYSE DES BESOINS
1. Identification des acteurs:
Directeur projet
Responsable technique Chef produit
Intervenant matériel Intervenant logiciel
Client 8/22

9. 2. Besoins fonctionnels
 Gestion des clients (ajout , modification , suppression)
 Gestion du personnel (ajout , modification , suppression)
 Gestion des produits (ajout , modification , suppression)
 Gestion des réclamations (envoie , modification ,annulation)
 Gestion des interventions (ajout , modification , suppression)
9/22

10. 3. Besoins non fonctionnels
10/22

11. III. CONCEPTION
11/22
1. Diagramme de cas d’utilisation
Consulter
PVinterventions
Gérer
réclamations
Consulter produit
Consulter
contrats
S’authentifier
« include»
« include»
« include»
« include»
Client

12. 12/22
Gérer comptes
Gérer rôles
Gérer
menus/items
Gérer produits
Consulter
réclamations
Gérer
interventions
Gérer contrats
S’authentifier
« include»
« include»
« include»
« include»
« include»
« include»
« include»
Directeur projet
Responsable

13. 13/22
Gérer
PVinterventions
Consulter
interventions
S’authentifier
Intervenant
« include»
« include»

14. 14/22
2. Diagramme de séquence « Gérer réclamations »

15. 15/22
3. Diagramme de classe

16. 16/22
4. Diagramme d’activité

17. 17/22
5. Architecture de l’application
Architecture 3-tiers

18. IV. RÉALISATION
1. Environnement de travail
18/22

19. 19/22
2. Etude de cas (Réclamation logicielle)

20. V. CONCLUSION ET PERSPECTIVE
 Intégration dans le monde professionnel.
 Avoir le sens d’écoute.
 Enrichir nos connaissances dans le développement des
applications web.
20/22
Conclusion

21.  La partie client de ce projet pourra être améliorer en une
application mobile.
 Intégrer le protocole de transfert hypertexte sécurisé (https).
21/22
Perspective

22. MERCI POUR VOTRE ATTENTION
22/22