0% ont trouvé ce document utile (0 vote)
101 vues64 pages

Rapport Finale DMADV de SsEq1.2

Le rapport présente le développement d'une application de gestion de covoiturage universitaire, visant à optimiser les déplacements au sein des communautés universitaires tout en réduisant l'empreinte carbone. En suivant la méthodologie DMADV, le projet aborde l'identification des besoins, la mesure de la qualité, l'analyse des causes, la conception de la solution et la validation des résultats. L'application, utilisant des technologies modernes comme Spring Boot et Angular, est conçue pour être intuitive et performante, facilitant les interactions entre conducteurs et passagers.

Transféré par

Wejden Timoumi
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd
0% ont trouvé ce document utile (0 vote)
101 vues64 pages

Rapport Finale DMADV de SsEq1.2

Le rapport présente le développement d'une application de gestion de covoiturage universitaire, visant à optimiser les déplacements au sein des communautés universitaires tout en réduisant l'empreinte carbone. En suivant la méthodologie DMADV, le projet aborde l'identification des besoins, la mesure de la qualité, l'analyse des causes, la conception de la solution et la validation des résultats. L'application, utilisant des technologies modernes comme Spring Boot et Angular, est conçue pour être intuitive et performante, facilitant les interactions entre conducteurs et passagers.

Transféré par

Wejden Timoumi
Copyright
© © All Rights Reserved
Nous prenons très au sérieux les droits relatifs au contenu. Si vous pensez qu’il s’agit de votre contenu, signalez une atteinte au droit d’auteur ici.
Formats disponibles
Téléchargez aux formats PDF, TXT ou lisez en ligne sur Scribd

République tunisienne

Ministère de l’Enseignement supérieur et de la Recherche scientifique


Université de La Manouba - Institut Supérieur des Arts Multimédia

RAPPORT DMADV

Sujet
Développement d’une application de Gestion de Covoiturage
Universitaire

Dans le cadre du module : QUALITE LOGICIEL

Réalisé par :  Anwer BenAbdallah


 Dhia Nahdi
 Louai Souei
 Yahya Ghdemsi

Supervisé par : Dr. Sana BenAbdallah

Année universitaire :2024-2025


Table des matières

INTRODUCTION GENERALE............................................................................................1

CHAPITRE I DEFINIR (DEFINE) : IDENTIFICATION DES BESOINS ET


OBJECTIFS...... ....................................................................................................................... 2

Introduction ...................................................................................................................... 2

La méthodologie QQOQCCP : ........................................................................................ 2

Préparation du Questionnaire de Recueil d'Informations ................................................ 3

Critères de Qualité (Critical to Quality - CTQ) ............................................................. 11

CHAPITRE II MESURER (MEASURE) : OPTIMISATION DE LA QUALITE PAR


UNE APPROCHE DYNAMIQUE ET PERSONNALISEE INTRODUCTION ............. 13

L'ADN de la sécurité : une surveillance proactive et itérative ..................................... 13

La performance redéfinie : qualité en temps réel, expérience utilisateur sans


compromis ............................................................................................................................ 13

L'expérience utilisateur : de la mesure à l'action continue ........................................... 14

La gestion des données : assurance qualité basée sur la traçabilité .............................. 14

Engagement et adoption : suivi de l’évolution des utilisateurs .................................... 15

Indicateurs de Performance Identifiés (KPIs) .............................................................. 15

Intégration des outils de mesure dans un cycle agile et flexible .................................. 15

Modèle de la qualité du produit basé sur la norme ISO/IEC 25010 ............................. 15

II. 8. 1 Les 8 caractéristiques et sous-caractéristiques de qualité ..................................... 16

II. 8. 2 Spécification des métriques pour chaque caractéristique (avec des règles
supplémentaires pour la mesure) ...................................................................................... 19

Modèle de la qualité à l’utilisation basé sur la norme ISO/IEC 25010 ........................ 24

II. 9. 1 Effectiveness (Efficacité) ...................................................................................... 24

II. 9. 2 Satisfaction ............................................................................................................ 25


II. 9. 3 Efficacité contextuelle .......................................................................................... 29

II. 9. 4 Efficiency .............................................................................................................. 30

CHAPITRE III ANALYSER (ANALYZE) : IDENTIFICATION DES CAUSES


RACINES 33

Introduction ................................................................................................................. 33

Analyse des problèmes : Exploration de l'expérience utilisateur (UX) ...................... 33

Étude de la concurrence : Différenciation par l'innovation ......................................... 34

Analyse des risques : Approche préventive et adaptative ........................................... 34

Diagramme d'Ishikawa ................................................................................................ 35

Approche pragmatique avec la méthode des 5 pourquoi ............................................ 35

CHAPITRE IV CREATION DE LA SOLUTION : DESIGN ET APPROCHE


STRATEGIQUE .................................................................................................................... 37

Introduction ................................................................................................................. 37

Définition de l'Interface Utilisateur (UI) : L’expérience Visuelle et Intuitive............ 37

Architecture Technique : Structure Solide pour une Application Évolutive .............. 38

Expérience Utilisateur : Une Navigation Optimale et Satisfaisante ........................... 38

Prototype et Validation : Valider Avant de Passer à l’Action .................................... 39

Diagramme des classes : ............................................................................................. 40

CHAPITRE V VERIFICATION (VERIFY) : VALIDATION DES RESULTATS...... 41

Introduction .................................................................................................................. 41

Adéquation fonctionnelle ............................................................................................. 41

V. 2. 1 Méthodologie ........................................................................................................ 41

V. 2. 2 Résultats des Tests ................................................................................................ 41

V. 2. 3 Problèmes Identifiés et Recommandations ........................................................... 45

Fiabilité......................................................................................................................... 45

Performance et efficacité .............................................................................................. 47

V. 4. 1 Performances Serveur ........................................................................................... 48

V. 4. 2 Performances Client.............................................................................................. 51
Sécurité ......................................................................................................................... 52

V. 5. 1 Implémentation de JWT (JSON Web Tokens) ..................................................... 53

V. 5. 2 Logique de Rafraîchissement du Token ............................................................... 53

V. 5. 3 Logique de Déconnexion (LogOut) ...................................................................... 54

CONCLUSION GENERALE............................................................................................... 59
INTRODUCTION GÉNÉRALE

Dans un monde en constante évolution, où la durabilité et l'efficacité occupent une place centrale dans la
planification des systèmes, l'importance de solutions innovantes pour les défis quotidiens ne peut être sous-
estimée. L'augmentation des déplacements au sein des communautés universitaires, associée à une prise de
conscience accrue de l'impact environnemental, a généré un besoin pressant d'optimiser les modes de
transport. C’est dans ce contexte que s’inscrit le projet de développement d’une application de gestion de
covoiturage universitaire, conçu pour répondre aux exigences de mobilité des étudiants, enseignants et
personnels tout en favorisant une démarche écoresponsable.

Ce rapport explore le processus de conception et de développement de cette application en s'appuyant sur


la méthodologie DMADV (Définir, Mesurer, Analyser, Concevoir, Vérifier), issue de l’approche Six
Sigma. Cette méthodologie, centrée sur l’amélioration continue et la qualité, guide chaque étape du projet,
depuis l’identification des besoins des utilisateurs jusqu’à la validation finale du produit. En adoptant cette
approche structurée, nous nous engageons à produire une solution performante, intuitive et évolutive.

L’objectif principal de cette application est de simplifier les interactions entre conducteurs et passagers
universitaires, en leur offrant un outil numérique qui non seulement facilite l’organisation des trajets, mais
contribue également à réduire l’empreinte carbone des déplacements. Cette vision est soutenue par des
choix technologiques robustes, comme l’intégration de Spring Boot pour le back-end et Angular pour le
front-end, assurant ainsi une expérience utilisateur fluide et sécurisée.

Le présent document détaille chaque phase du projet, en mettant en lumière les choix stratégiques, les
analyses effectuées et les solutions proposées. En commençant par une compréhension approfondie des
besoins des parties prenantes, nous abordons ensuite la conception de l’application, en passant par les
mécanismes de mesure et d’analyse de la qualité. Chaque chapitre illustre l'engagement à aligner les attentes
des utilisateurs avec des normes de qualité rigoureuses, assurant ainsi une réponse précise aux défis
identifiés.

En synthèse, ce rapport vise à démontrer comment une approche méthodologique rigoureuse et une vision
centrée sur l'utilisateur peuvent converger pour créer une solution innovante et durable, capable de
transformer les pratiques de mobilité au sein des universités.

1
CHAPITRE I DEFINIR (DEFINE) : IDENTIFICATION DES
BESOINS ET OBJECTIFS

Introduction

Pour garantir une compréhension claire des besoins des utilisateurs et des objectifs du projet, nous avons
structuré cette phase en suivant une approche axée sur la clarification des attentes, des parties prenantes et
des priorités fonctionnelles.

La méthodologie QQOQCCP :
1. Parties Prenantes et Utilisateurs Principaux (Qui ?)

● Conducteurs : Étudiants, enseignants ou membres du personnel administratif souhaitant proposer


des trajets.
● Passagers : Étudiants, enseignants ou personnels recherchant des trajets en covoiturage.
● Administrateurs : Responsables de la gestion et de la supervision de l’application (modération,
suivi des abus, statistiques).

2. Objectifs Fonctionnels (Quoi ?)

Le projet a pour objectif de développer une application web destinée à :

● Mettre en relation les conducteurs et passagers d’une communauté universitaire.


● Simplifier la gestion des trajets, des réservations et des interactions entre utilisateurs.
● Réduire l’empreinte carbone des déplacements universitaires grâce à une solution numérique
adaptée.

3. Où et Comment l'application sera utilisée (Où ?)

● Contexte d’utilisation : Dans le cadre d’un campus universitaire pour des déplacements domicile-
campus ou entre campus.
● Accessibilité : Application en ligne, accessible via navigateur web sur ordinateurs et appareils
mobiles.

4. Cadre Temporel (Quand ?)

● Livraison du prototype (MVP) : Inclura les fonctionnalités essentielles comme la création de


trajets, la recherche avancée, l’inscription et la gestion des réservations.
● Améliorations successives : Intégration des fonctionnalités avancées (messagerie, API météo,
gamification) après validation du MVP.

2
5. Approche Technologique (Comment ?)

● Back-end : Spring Boot (gestion des données, sécurité, MVC).


● Front-end : Angular (interface utilisateur réactive et moderne).
● Base de données : MySQL pour stocker les informations des utilisateurs, trajets et réservations.
● Services externes :
○ API Google Maps : Géolocalisation et calculs d’itinéraires.
○ Service de notifications : Envoi d’emails ou alertes en temps réel.
● Sécurisation : Utilisation de Spring Security et JWT pour protéger les données utilisateurs et gérer
les permissions.

6. Le Coût du Projet (Combien ?)

Le coût du projet comprend les éléments suivants :

● Coûts de développement :
○ Les ressources humaines (équipe technique et de gestion de projet).
○ Les outils de développement et de collaboration, comme GitHub et Maven.
● Coûts des ressources techniques :
○ Hébergement sur un serveur pour déployer l'application.
○ Gestion de la base de données MySQL.
● Estimation initiale :
○ Un délai de développement de 3 à 6 mois pour atteindre un MVP fonctionnel.
○ Des budgets additionnels pour les améliorations continues.

7. Le besoin à cette application (Pourquoi ?)

Le développement de cette application répond à des besoins spécifiques et offre des avantages clairs :

● Faciliter les déplacements universitaires : En mettant en relation conducteurs et passagers,


l’application simplifie l'organisation des trajets au sein des communautés universitaires.
● Réduction de l’impact environnemental : Promouvoir le covoiturage diminue le nombre de
véhicules en circulation et réduit les émissions de carbone.
● Renforcer le sentiment de communauté : En connectant étudiants, enseignants et personnel
administratif, l'application crée des opportunités de collaboration et de partage au sein des campus.
● Offrir une solution numérique innovante : Répondre à des besoins actuels en matière de mobilité
et de gestion des trajets grâce à une interface intuitive et performante.

Préparation du Questionnaire de Recueil d'Informations

Pour approfondir notre compréhension des besoins des utilisateurs finaux et des parties prenantes, nous
avons élaboré un questionnaire structuré. Ce dernier a été distribué aux principaux acteurs identifiés
(étudiants, enseignants, administrateurs).

3
Objectifs du questionnaire :

● Identifier les attentes prioritaires des utilisateurs en matière de fonctionnalités.


● Recueillir les contraintes techniques ou organisationnelles liées à l’utilisation de l’application.
● Évaluer les préférences en termes de design et d’ergonomie.

Types de Questions Idéales pour un Questionnaire

Pour améliorer un questionnaire futur, voici les types de questions idéales :

1. Questions fermées :

• Exemple : "Quel est votre rôle à l'université ?"


• Avantage : Faciles à analyser quantitativement.

Questions à choix multiples :

• Exemple : "Quelle fonctionnalité est la plus importante pour vous ?"


• Avantage : Permet d'obtenir des priorités claires.

2. Questions échelonnées (Likert) :

• Exemple : "Sur une échelle de 1 à 5, quelle est l'importance d'une interface intuitive ?"
• Avantage : Permet d'évaluer des niveaux d'opinion.

3. Questions ouvertes :

• Exemple : "Quels problèmes majeurs avez-vous rencontrés ?"


• Avantage : Recueille des suggestions et feedbacks précis.

4. Études Supplémentaires Proposées

Pour approfondir l'analyse, les études suivantes sont recommandées :

1. Analyse des besoins des conducteurs :

• Enquête ciblée pour comprendre ce qui encouragerait les utilisateurs à proposer des
trajets.

2. Tests d’utilisabilité de l'application :

• Évaluer l'interface et l'expérience utilisateur via des sessions de tests.

3. Analyse des trajets types :

• Identifier les heures et les trajets les plus fréquents pour optimiser l'offre.

4
4. Enquête sur les freins à l'adoption :

• Comprendre pourquoi certains utilisateurs ne souhaitent pas utiliser le covoiturage.

Questionnaire proposé :

5
Synthèse des résultats :

Section 1 : Informations Générales

1. Quel est votre rôle à l'université ?

• 73,7 % des répondants sont étudiants.


• 21,1 % sont enseignants.
• 5,3 % appartiennent au personnel administratif.
• Conclusion : L'application doit principalement cibler les étudiants tout en étant adaptable
aux enseignants et au personnel administratif.

6
1. Quelle utilisation ferez-vous principalement de l'application ?

• 52,6 % en tant que passager.


• 36,8 % en tant que conducteur.
• 10,5 % pour les deux rôles.
• Conclusion : Il y a un déséquilibre entre l'offre et la demande. Il faudra encourager plus
de conducteurs.

2. Fréquence des trajets vers l'université :

• 73,7 % des utilisateurs se déplacent quotidiennement.


• 26,3 % se déplacent quelques fois par semaine.
• Conclusion : Une forte fréquence de trajets justifie la pertinence d'une application pour
réduire les coûts et optimiser les déplacements.

7
Section 2 : Attentes Fonctionnelles

1. Fonctionnalités les plus importantes :

• Recherche et réservation de trajets : 52,6 %.


• Notifications : 52,6 %.
• Messagerie interne : 52,6 %.
• Publication de trajets (conducteur) : 42,1 %.
• Conclusion : Les utilisateurs prioritaires veulent trouver des trajets facilement, recevoir
des notifications, et communiquer via une messagerie.

1. Temps acceptable pour la recherche :

• Moins de 5 secondes : 84,2 %.

8
• Conclusion : La rapidité de l'application est essentielle pour assurer une bonne
expérience utilisateur.

2. Préférence de notifications :

• Notifications push : 52,6 %.


• Email et push : 36,8 %.
• Conclusion : Intégrer des notifications push tout en offrant une option de double canal.

Section 3 : Expérience Utilisateur

1. Importance d'une interface intuitive :

• 73,7 % des utilisateurs la considèrent comme très importante.

9
• Conclusion : Une interface simple et ergonomique est cruciale pour l'adoption de
l'application.

1. Utilisation d'autres applications de covoiturage :

○ 20 % ont déjà utilisé une autre application.


○ Problèmes rencontrés :
■ Nombre réduit de conducteurs.
■ Délais d'attente trop longs.

5. Propositions d'Actions

Action 1 : Encourager les conducteurs

● Mettre en place un système de récompenses pour les conducteurs (ex : bons d'achat, points
cumulables).

● Simplifier le processus de publication des trajets.

Action 2 : Optimiser l'expérience utilisateur

● Assurer une interface simple, intuitive et rapide.

● Implémenter des notifications push et configurables.

● Améliorer la rapidité de la recherche de trajets (éviter les délais supérieurs à 5 secondes).

Action 3 : Promouvoir l'application

● Lancer une campagne de sensibilisation à l'université.

● Organiser des démonstrations de l'application.

10
● Créer des tutoriels et guides pour les nouveaux utilisateurs.

Action 4 : Analyse continue des besoins

● Collecter régulièrement des feedbacks pour améliorer les fonctionnalités.

● Mettre en place un support utilisateur pour traiter les problèmes rapidement.

Critères de Qualité (Critical to Quality - CTQ)


Pour garantir une application robuste et performante, des critères de qualité sont établis en fonction des
attentes des utilisateurs et des objectifs du projet.

Accessibilité et Performance

● Critère : L'application doit offrir une expérience rapide et fluide, particulièrement pour les
recherches de trajets.
● Objectif : Les recherches doivent s’exécuter en moins de 2 secondes et la page d’accueil doit se
charger en moins de 3 secondes.

Sécurité des Données

● Critère : Assurer la protection des informations personnelles (nom, email, trajets, réservations).
● Objectif :
○ Crypter les mots de passe et données sensibles.
○ Utiliser des tokens JWT pour les sessions, limitant les risques d’accès non autorisé.

Satisfaction de l’Utilisateur

● Critère : L’interface doit être conviviale et intuitive, adaptée aux besoins des utilisateurs
universitaires.
● Objectif : Obtenir un taux de satisfaction supérieur à 90 % lors des tests utilisateurs grâce à une
navigation claire et des fonctionnalités accessibles.

Fiabilité des Réservations

● Critère : Assurer une gestion sans erreur des trajets proposés, réservés ou annulés.
● Objectif : Maintenir un taux d’erreur inférieur à 1 % dans la gestion des réservations et trajets.

Communication et Notifications

● Critère : Les conducteurs et passagers doivent recevoir les informations importantes en temps
opportun.
● Objectif : Garantir une livraison des notifications (emails ou messages in-app) en moins de 5
secondes après une action.

11
En suivant cette approche structurée et détaillée, nous posons les bases d’un projet bien défini, axé sur les
besoins spécifiques des utilisateurs universitaires et sur les principes de qualité logicielle.

12
CHAPITRE II MESURER (MEASURE) : OPTIMISATION DE LA
QUALITE PAR UNE APPROCHE DYNAMIQUE ET
PERSONNALISEE INTRODUCTION

Dans le cadre de la phase "Mesurer", nous mettons en place un système de suivi de la qualité unique et
flexible, adapté à notre projet de gestion de covoiturage universitaire. L’objectif est de dépasser les
métriques traditionnelles pour adopter une approche réactive qui évolue avec les besoins spécifiques des
utilisateurs et les objectifs du projet. L’application étant un produit dynamique, nous allons mesurer la
qualité sous plusieurs angles innovants en utilisant des outils et des processus de suivi intégrés.

L'ADN de la sécurité : une surveillance proactive et itérative

La sécurité, au cœur de notre application, nécessite un suivi continu et une adaptation à chaque itération du
projet.

● Suivi de l’authentification avec un système de validation constant :

○ Critère de succès : Précision du suivi des tentatives de connexion, avec un système d’alertes
en temps réel.
○ Outils et Processus : Utilisation de Spring Security couplé à un dashboard interne affichant
en direct les tentatives d’authentification, l'historique des erreurs et les tendances.
○ Objectif innovant : Implémentation d’un système de machine learning pour détecter des
motifs inhabituels dans les tentatives de connexion.

● Cryptage des données sensibles : une mesure continue de la conformité :

○ Critère de succès : Taux de conformité des mécanismes de cryptage (par exemple, AES
pour les mots de passe).
○ Outils et Processus : Mise en place d’une revue de code automatique assurant la conformité
des modules aux normes de sécurité.
○ Objectif innovant : Réalisation de tests mensuels de pénétration avec OWASP ZAP,
documentant les vulnérabilités détectées.

La performance redéfinie : qualité en temps réel, expérience


utilisateur sans compromis

Nous adoptons une approche basée sur des sprints de performance où chaque mise à jour du produit est
évaluée selon des critères spécifiques.

● Optimisation des trajets en temps réel : une performance adaptative :

13
○ Critère de succès : Réactivité des trajets proposés selon l’heure de la journée, la charge des
serveurs et la demande.
○ Outils et Processus : Intégration de Spring Boot Actuator avec des métriques en temps réel
sur un tableau de bord interactif.
○ Objectif innovant : Réduction des délais de réponse en temps réel de 20 % à chaque
itération majeure.
● Utilisation d’un système de mesure de la disponibilité proactive :

○ Critère de succès : Nombre d’incidents critiques détectés automatiquement.


○ Outils et Processus : Surveillance via Prometheus couplée à Kibana pour observer les logs
en direct.
○ Objectif innovant : Atteindre une disponibilité de 99,95 % avec une solution de failover
automatique.

L'expérience utilisateur : de la mesure à l'action continue

L’objectif est de créer une boucle de rétroaction constante pour une adaptation instantanée aux besoins des
utilisateurs.

● Retours d’expérience utilisateur instantanés :

○ Critère de succès : Nombre d’interactions des utilisateurs via un mécanisme de feedback


intégré après chaque trajet.
○ Outils et Processus : Notifications push pour récolter des feedbacks immédiats.
○ Objectif innovant : Analyse automatique des feedbacks par algorithme pour identifier les
points de friction en temps réel.
● Analyse de l’engagement à travers les interactions sociales :

○ Critère de succès : Taux de partage des trajets via les réseaux sociaux.
○ Outils et Processus : Fonction de partage sur Facebook, Twitter et WhatsApp avec suivi
des interactions.
○ Objectif innovant : Augmentation des partages de trajets de 30 % par cycle de mise à jour.

La gestion des données : assurance qualité basée sur la traçabilité

● Audit continu de la gestion des trajets et réservations :


○ Critère de succès : 100 % des trajets et réservations traçables avec historique accessible.
○ Outils et Processus : Utilisation d’un Data Lake pour stocker et auditer les données.
○ Objectif innovant : Intégration d’un Data Warehouse audité mensuellement via un outil de
business intelligence.

14
Engagement et adoption : suivi de l’évolution des utilisateurs

● Analyse de la dynamique d’adoption :

○ Critère de succès : Nombre d’utilisateurs abandonnant l’application après 1, 3 et 6 mois.


○ Outils et Processus : Suivi via Mixpanel et analyse comportementale.
○ Objectif innovant : Algorithme prédictif pour anticiper l’abandon des utilisateurs et mettre
en place des actions correctives.
● Suivi de la valeur utilisateur à travers des cohortes :

○ Critère de succès : Évolution des utilisateurs par cohortes.


○ Outils et Processus : Création de cohortes basées sur les comportements et interactions.
○ Objectif innovant : Recommandations personnalisées pour augmenter l’engagement.

Indicateurs de Performance Identifiés (KPIs)

Pour mesurer la satisfaction et répondre aux attentes des utilisateurs, nous avons défini les KPIs suivants :

1. Temps acceptable pour rechercher un trajet (en secondes).


2. Temps acceptable pour effectuer une réservation (en secondes).
3. Importance des notifications (emails ou push).
4. Fonctionnalités prioritaires pour les utilisateurs.
5. Facilité d’utilisation souhaitée.

Intégration des outils de mesure dans un cycle agile et flexible

Les outils de mesure seront intégrés à chaque phase du développement, en utilisant des cycles agiles pour
une amélioration continue des métriques :

● Implémentation d’un tableau de bord personnalisé pour chaque équipe permettant un suivi des KPI
en temps réel.

Révision trimestrielle des objectifs de performance en fonction des retours utilisateurs, avec ajustements
des priorités.

Modèle de la qualité du produit basé sur la norme ISO/IEC


25010

L’évaluation de la qualité d’une application repose sur des caractéristiques définies par la norme ISO/IEC
25010. Cette norme décrit huit caractéristiques principales et leurs sous-caractéristiques, qui sont
essentielles pour garantir un produit logiciel performant, fiable, sécurisé et satisfaisant pour les utilisateurs.

15
Pour l’application de gestion de covoiturage universitaire, nous appliquons cette norme en l’adaptant au
contexte spécifique du projet.

II. 8. 1 Les 8 caractéristiques et sous-caractéristiques de qualité

1. Adéquation fonctionnelle :

○ Évaluer si l’application répond aux besoins des utilisateurs.

○ Sous-caractéristiques :

■ Complétude fonctionnelle : Toutes les fonctionnalités nécessaires (création de


trajets, réservation, notifications) doivent être présentes.

■ Correction fonctionnelle : Chaque fonctionnalité doit fonctionner sans erreur.

■ Pertinence fonctionnelle : Les fonctionnalités doivent correspondre aux besoins


spécifiques des utilisateurs (ex. : recherche avancée, messagerie interne).

2. Fiabilité :

○ Garantir une disponibilité et une stabilité élevées.

○ Sous-caractéristiques :

■ Maturité : Réduire les bugs et anomalies.

16
■ Disponibilité : Maintenir un taux d’uptime élevé (> 99%).

■ Tolérance aux fautes : L’application doit continuer à fonctionner malgré des erreurs
mineures.

■ Capacité de récupération : L’application doit redémarrer rapidement après une


panne.

3. Performance et efficacité :

○ Mesurer la rapidité et l’efficacité de l’application.

○ Sous-caractéristiques :

■ Comportement temporel : Temps de réponse des API (< 2 secondes).

■ Utilisation des ressources : Consommation optimisée des ressources système.

■ Capacité : Gérer efficacement un grand nombre d’utilisateurs simultanés (ex. : 500


requêtes par seconde).

4. Compatibilité :

○ Assurer le bon fonctionnement de l’application sur différents environnements.

○ Sous-caractéristiques :

■ Coexistence : L’application doit fonctionner en parallèle avec d’autres logiciels (ex.


: outils de messagerie).

■ Interopérabilité : Capacité à intégrer des services tiers comme Google Maps ou


Firebase.

5. Sécurité :

○ Protéger les données des utilisateurs.

○ Sous-caractéristiques :

■ Confidentialité : Protéger les informations sensibles.

■ Intégrité : Prévenir toute modification non autorisée des données.

■ Authentification : Garantir que seuls les utilisateurs autorisés accèdent à


l’application.

■ Auditabilité : Permettre de tracer les actions pour identifier les failles.

6. Maintenabilité :

17
○ Faciliter les modifications et mises à jour.

○ Sous-caractéristiques :

■ Modularité : Code structuré en modules indépendants.

■ Réutilisabilité : Favoriser la réutilisation des composants existants.

■ Analysabilité : Facilité à diagnostiquer les problèmes.

■ Modifiabilité : Capacité à intégrer de nouvelles fonctionnalités rapidement.

■ Testabilité : Faciliter les tests unitaires et d’intégration.

7. Utilisabilité :

○ Garantir une expérience utilisateur intuitive.

○ Sous-caractéristiques :

■ Appréhensibilité : Interface simple et claire.

■ Apprentissage : Les utilisateurs doivent maîtriser l’application rapidement.

■ Opérabilité : Les tâches doivent être faciles à exécuter.

■ Esthétique : Interface visuellement attrayante.

■ Accessibilité : Accessible aux utilisateurs ayant des besoins spécifiques (ex. :


options pour malvoyants).

8. Portabilité :

○ Faciliter l’utilisation de l’application sur différents environnements.

○ Sous-caractéristiques :

■ Adaptabilité : Fonctionne sur mobile, tablette et PC.

■ Installabilité : Installation simple et rapide.

■ Remplaçabilité : Facilité de migration vers une nouvelle version.

18
II. 8. 2 Spécification des métriques pour chaque caractéristique (avec des règles
supplémentaires pour la mesure)

Pour chaque caractéristique et sous-caractéristique, des règles de mesure spécifiques sont ajoutées pour
garantir une évaluation objective et complète.

1. Adéquation fonctionnelle

● Complétude fonctionnelle :

○ Métrique : Pourcentage de fonctionnalités implémentées et validées.

○ Règle de mesure :

■ Définir un plan de validation couvrant 100% des spécifications fonctionnelles.

■ Vérifier que chaque fonctionnalité principale (gestion des trajets, réservation,


messagerie) est implémentée et testée.

■ Fonctionnalités partiellement implémentées comptent pour 50%.

● Correction fonctionnelle :

○ Métrique : Taux de réussite des tests fonctionnels (tests unitaires, d’intégration).

○ Règle de mesure :

■ Exécuter des scénarios de test couvrant toutes les combinaisons possibles.

■ Considérer comme "réussi" uniquement les tests validés sans erreur.

■ Un test échoué réduit le taux global proportionnellement au nombre total de tests.

● Pertinence fonctionnelle :

○ Métrique : Score de satisfaction utilisateur (via questionnaire).

○ Règle de mesure :

■ Attribuer une échelle de 1 à 10 pour évaluer chaque fonctionnalité.

■ Moyenne calculée uniquement si ≥ 70% des utilisateurs répondent.

2. Fiabilité

19
● Disponibilité :

○ Métrique : Pourcentage d’uptime.

○ Règle de mesure :

■ Utiliser un outil de monitoring (ex. : New Relic) pour mesurer le temps total
d'indisponibilité.

■ Calculer :

■ Le seuil est fixé à 99% pour valider la métrique.

● Maturité :

○ Métrique : Nombre moyen de bugs signalés par mois.

○ Règle de mesure :

■ Considérer uniquement les bugs classés comme critiques ou majeurs dans un outil
de suivi (ex. : Jira).

■ Calculer la moyenne sur une période de 3 mois minimum.

● Tolérance aux fautes :

○ Métrique : Taux de récupération après une erreur.

○ Règle de mesure :

■ Simuler des scénarios d’erreur (ex. : coupure réseau, requêtes mal formées).

■ Mesurer le nombre d’erreurs récupérées automatiquement sur le total d’erreurs


injectées.

● Capacité de récupération :

○ Métrique : Temps moyen de récupération après une panne (MTTR).

○ Règle de mesure :

■ Chronométrer la durée entre la détection de la panne et le retour complet du service.

■ Calculer la moyenne sur plusieurs incidents simulés ou réels.

20
3. Performance et efficacité

● Comportement temporel :

○ Métrique : Temps moyen de réponse des API.

○ Règle de mesure :

■ Utiliser un outil comme Postman ou JMeter pour envoyer des requêtes répétées.

■ Calculer la moyenne sur 1000 requêtes, avec une charge variable (ex. : 10 à 500
utilisateurs simultanés).

● Capacité :

○ Métrique : Nombre maximal de requêtes supportées par seconde.

○ Règle de mesure :

■ Exécuter des tests de charge croissants (ex. : 100 à 1000 requêtes/s).

■ Identifier le seuil où le taux d’erreurs dépasse 5%.

4. Compatibilité

● Coexistence :

○ Métrique : Taux de compatibilité avec d'autres applications/services.

○ Règle de mesure :

■ Tester l’intégration avec au moins 3 services tiers (ex. : Google Maps, Firebase).

■ Un test échoué diminue la métrique de 33%.

● Interopérabilité :

○ Métrique : Pourcentage de fonctionnalités interopérables.

○ Règle de mesure :

■ Vérifier si les données échangées entre services sont conformes aux spécifications
(ex. : format JSON, respect des standards API REST).

21
5. Sécurité

● Confidentialité :

○ Métrique : Pourcentage d’attaques bloquées.

○ Règle de mesure :

■ Simuler des attaques (tests de pénétration) et mesurer celles bloquées


automatiquement.

■ Une attaque réussie diminue la métrique proportionnellement.

● Authentification :

○ Métrique : Taux de connexions sécurisées réussies.

○ Règle de mesure :

■ Vérifier que 100% des connexions passent par un protocole sécurisé (ex. : HTTPS).

6. Maintenabilité

● Testabilité :

○ Métrique : Taux de couverture des tests unitaires.

○ Règle de mesure :

■ Utiliser un outil comme SonarQube pour analyser le pourcentage de lignes de code


couvertes par les tests.

■ Le seuil minimum est fixé à 90%.

● Modifiabilité :

○ Métrique : Temps moyen pour intégrer une nouvelle fonctionnalité.

○ Règle de mesure :

■ Mesurer le temps entre la demande de modification et son déploiement en


production.

7. Utilisabilité

22
● Appréhensibilité :

○ Métrique : Temps moyen pour accomplir une tâche simple.

○ Règle de mesure :

■ Demander à un échantillon de 10 utilisateurs de réaliser une tâche simple (ex. :


réserver un trajet).

■ Calculer la moyenne des temps enregistrés.

● Esthétique :

○ Métrique : Score esthétique.

○ Règle de mesure :

■ Utiliser une échelle de 1 à 10 dans un questionnaire soumis à un échantillon


d’utilisateurs.

8. Portabilité

● Adaptabilité :

○ Métrique : Nombre de plateformes compatibles.

○ Règle de mesure :

■ Tester l’application sur au moins 3 environnements (ex. : Android, iOS, navigateurs


web).

● Installabilité :

○ Métrique : Temps moyen pour installer l’application.

○ Règle de mesure :

■ Mesurer le temps entre le début du téléchargement et la première ouverture réussie.

Ces règles permettent de garantir des mesures objectives et standardisées, facilitant l’analyse de la qualité
globale de votre application.

23
Modèle de la qualité à l’utilisation basé sur la norme ISO/IEC
25010
Nous nous concentrons sur deux caractéristiques essentielles : Effectiveness (Efficacité) la Satisfaction,
chacune ayant ses propres sous-caractéristiques.

II. 9. 1 Effectiveness (Efficacité)


La caractéristique de l’efficacité évalue dans quelle mesure le produit ou le service atteint ses objectifs et
répond aux besoins de l’utilisateur. Les mesures clés comprennent la réalisation des tâches, la précision
des résultats et la satisfaction des utilisateurs dans l’accomplissement de leurs objectifs.

● Exactitude : Garantir que les trajets affichés correspondent aux critères de recherche des utilisateurs
(trajet, heure, distance).

● Efficacité en termes de ressources : Mesurer la vitesse d’exécution pour rechercher, proposer un trajet
ou réserver.

Arbre de Critères de la Qualité (CTQ Tree)

VOC : Temps de recherche rapide et exactitude des résultats

Type de test

II. 9. 1. 2. a :Test fonctionnels

Les tests fonctionnels sont un type de test de boîte noire qui évalue la conformité d’un système ou d’un
composant avec les exigences fonctionnelles énoncées. Les tests fonctionnels spécifient ce que fait le
système.

24
Outils : Selenium framework de test open source le plus connu utilisé pour l’automatisation des tests
fonctionnels pour les applications Web basées sur un navigateur.

Lien : https://www.selenium.dev/

II. 9. 1. 2. b : Test de perfermance

Les tests de performance sont une étape essentielle du processus de développement logiciel qui permet
réellement aux organisations de fournir des applications de haute qualité.

Outils : Apache jmeter logiciel open source largement adopté et entièrement conçu en Java. Son objectif
principal est d’effectuer des tests de charge pour le comportement fonctionnel et d’évaluer les
performances.

Lien : https://jmeter.apache.org/

II. 9. 2 Satisfaction

La satisfaction des utilisateurs est une caractéristique fondamentale qui englobe deux sous-caractéristiques
cruciales : Usefulness (Utilité) et Trust (Confiance).

25
● Usefulness (Utilité) : La sous-caractéristique de l’utilité évalue dans quelle mesure le produit ou le
service répond aux besoins et attentes spécifiques de l’utilisateur. Cela inclut la pertinence des
fonctionnalités, la facilité d’utilisation et la contribution globale à la réalisation des objectifs de l’utilisateur.

● Trust (Confiance) : La confiance est un élément clé de la satisfaction. Elle mesure dans quelle mesure
les utilisateurs ont confiance en la fiabilité, la sécurité et la transparence du produit ou du service. Les
éléments tels que la sécurité des données, la cohérence des performances et la clarté des communications
influent sur la confiance des utilisateurs.

Arbre de Critères de la Qualité (CTQ Tree)

VOC : amélioration du Satisfaction utilsateur

Stratégies pour Atteindre un Haut Niveau de Satisfaction et de Sécurité

II. 9. 2. 2. a :Enquêtes post-utilisation

Création des questionnaires standardisés (Net Promoter Score (NPS), Customer Effort Score (CES))

● NPS est un indicateur global de la satisfaction et de la fidélité client, facile à utiliser, reproductible dans
le temps et par secteur d’activité

26
● Customer Effort Score est un indicateur assez récent et plus spécifique que les deux précédents.
L’objectif est de mesurer le niveau d’effort que le client a dû fournir pour obtenir une réponse satisfaisante
à son besoin.

Outils : Typeform est un outil simple, intuitif et puissant, permettant de réaliser des formulaires, enquêtes,
questionnaires… le tout avec un design très soigné

II. 9. 2. 2. b : Stratégies pour la gestion des incidents de sécurité

1. Évaluation initiale de la sécurité : utilisation des outils de tests automatisés comme OWASP ZAP

27
Lien : https://www.zaproxy.org/

2. Surveiller et détecter les incidents : Configurer un système de surveillance des activités suspectes à
l'aide d'outils SIEM (Splunk) avec la mise en place des alertes en temps réel pour détecter.

Lien : https://www.splunk.com

3. Réagir rapidement aux incidents : Automatiser des réponses immédiates comme le blocage d'IP
suspecte avec des outils comme Fail2Ban

Lien : https://github.com/fail2ban/fail2ban

28
II. 9. 3 Efficacité contextuelle

L’efficacité contextuelle est une caractéristique fondamentale qui englobe deux sous-caractéristiques
cruciales : flexibilité et tolérance aux erreurs.

● flexibilité : Nombre d’appareils/supports compatibles.

● Tolérance aux erreurs : Nombre moyen d’erreurs utilisateur corrigées automatiquement.

Arbre de Critères de la Qualité (CTQ Tree)

VOC : Support multi-plateformes et tolérance aux erreurs

Stratégies pour Atteindre un Haut Niveau d'efficacité contextuelle

II. 9. 3. 2. a :Test de compatibilité

Les tests de compatibilité font partie intégrante de nombreuses stratégies d’assurance qualité, permettant
aux entreprises de vérifier si leurs logiciels fonctionnent correctement sur différentes plateformes.

Outils : BrowserStack facilite les tests inter-navigateurs sur 20 000 combinaisons appareil-navigateur-
OS, ce qui en fait un choix de confiance pour Tesco, Shell, NVIDIA, Discovery, Wells Fargo et plus de 50
000 clients. Les équipes peuvent accéder à un large éventail de navigateurs, des anciennes versions aux
dernières versions bêta et de développement, ainsi qu’aux appareils Android/iOS les plus récents.

29
Lien : https://www.browserstack.com/

II. 9. 3. 2. b : Centralisation et analyse des journaux d’erreurs

Les erreurs sont automatiquement regroupées par type et fréquence, ce qui nous permet de prioriser les
problèmes les plus critiques, souvent avant qu'ils n'affectent un grand nombre d'utilisateurs.

Outils : Sentry offre également des fonctionnalités de notifications en temps réel, nous permettant d'être
immédiatement alertés de tout incident, afin de réagir plus rapidement. Par ailleurs, la plateforme permet
de suivre l'évolution des erreurs grâce à une interface claire et un tableau de bord intuitif.

Lien : https://isamm-jo.sentry.io

II. 9. 4 Efficiency

L’Efficience est une caractéristique fondamentale qui englobe deux sous-caractéristiques cruciales :
Utilisation optimale des ressources système (System Resource Utilization) et Efficacité énergétique
(Energy Efficiency).

● Utilisation optimale des ressources système : L'application doit être conçue pour minimiser l'utilisation
des ressources (processeur, mémoire, réseau) tout en offrant des fonctionnalités complètes.

● Efficacité énergétique (Energy Efficiency) : L'application doit être optimisée pour réduire la
consommation d'énergie des appareils mobiles, notamment en évitant des processus en arrière-plan inutiles
ou en optimisant la gestion des connexions réseau.

30
Arbre de Critères de la Qualité (CTQ Tree)

VOC : Utilisation optimale des ressources système et énergie

Stratégies pour Atteindre un Haut Niveau d'efficience

L'objectif principal de cette stratégie est de maximiser l'efficacité de l'application en termes de réactivité,
de gestion des ressources système et de consommation énergétique, tout en garantissant une expérience
utilisateur fluide et performante. Cela implique des pratiques de développement, de tests et d'optimisation
continues.

1 : Planification et Définition des Besoins

● Définir les exigences fonctionnelles et non fonctionnelles :

○ Spécifier les objectifs de consommation des ressources (≤ 100 Mo de mémoire, ≤ 15% de CPU).

○ Identifier les objectifs de consommation énergétique (≤ 15% de la batterie par heure d’utilisation
active).

● Prioriser les fonctionnalités essentielles en fonction de l'impact sur l'efficacité.

○ Limiter les fonctionnalités énergivores (ex. géolocalisation continue) et utiliser des alternatives efficaces
comme la mise en cache et la gestion des connexions réseau.

31
2 : Conception et Architecture

● Utiliser une architecture modulaire et performante :

○ Adopter une architecture optimisée qui permet de mieux gérer les ressources (par exemple, en utilisant
des design patterns comme le Singleton ou le Lazy Loading).

○ Séparer les processus gourmands en ressources dans des modules distincts, afin d'éviter les impacts sur
les performances globales.

● Choisir des frameworks et des technologies performantes :

○ Utiliser Flutter (ou d'autres frameworks) pour son efficacité dans la gestion des ressources et son
approche multiplateforme.

3 : Optimisation des Performances et des Ressources

● Optimisation des requêtes réseau :

○ Utiliser des techniques comme la mise en cache des données (pour les trajets fréquents ou les informations
utilisateurs) pour réduire les appels réseau.

○ Implémenter des requêtes asynchrones pour éviter de bloquer le fil d’exécution principal.

● Réduire la consommation de la batterie et des ressources système :

○ Mettre en place des mécanismes pour réduire la fréquence des requêtes réseau et utiliser le mode backoff
exponentiel pour les tentatives de connexion.

○ Limiter les calculs intensifs à des moments où l'application est au premier plan et gérer intelligemment
les tâches en arrière-plan.

○ Mettre en place un mode économie d’énergie, en optimisant l’utilisation de la géolocalisation, des


notifications et des capteurs.

32
CHAPITRE III ANALYSER (ANALYZE) : IDENTIFICATION
DES CAUSES RACINES

Introduction

La phase ANALYZE constitue un point pivot dans la méthodologie DMADV, permettant d’identifier et
de comprendre les causes profondes des problématiques rencontrées lors du développement de l'application.
À travers des outils d’analyse tels que le diagramme d’Ishikawa, les méthodes des 5 pourquoi ou encore
l’étude de la concurrence, cette étape vise à établir un diagnostic précis des obstacles, des risques et des
opportunités.

L’objectif est de s'assurer que chaque problème détecté trouve une solution adaptée et que les choix
technologiques, fonctionnels et stratégiques soient en adéquation avec les attentes des utilisateurs. Cette
démarche garantit une base solide pour les phases ultérieures de conception et de validation.

Analyse des problèmes : Exploration de l'expérience utilisateur


(UX)

L'objectif ici est d'adopter une approche orientée utilisateur pour identifier les problèmes dans l’application
en prenant en compte la fluidité de l’expérience et la satisfaction globale. Cette analyse se concentre sur les
actions spécifiques des utilisateurs dans l’application et leurs frustrations possibles à chaque étape clé.

Problèmes potentiels à explorer :

● Processus de recherche de trajets inefficace : L’une des préoccupations majeures peut être que
les utilisateurs trouvent la recherche de trajets trop complexe. Au lieu de simplement regarder la
durée des recherches, nous devons étudier la pertinence des critères de recherche, leur intuitivité et
la manière dont les résultats sont affichés. L'intégration d'une fonctionnalité de tri des résultats en
fonction des préférences utilisateur pourrait être une piste d'amélioration.

● Conflits dans la gestion des trajets réservés : Il est essentiel de comprendre où les utilisateurs
rencontrent des obstacles lorsqu'ils réservent un trajet ou gèrent leur réservation. Cela peut
concerner la synchronisation des trajets proposés par les conducteurs et les besoins des passagers.
Nous devrons vérifier s’il y a des incohérences ou des retards dans la mise à jour des trajets réservés
et les places disponibles.

● Manque d’accessibilité mobile : L'accessibilité des fonctionnalités sur différentes plateformes


(mobile, tablette, ordinateur) peut être un problème majeur. Si l’application n’est pas entièrement
responsive, cela peut empêcher une partie importante des utilisateurs de l'utiliser dans de bonnes
conditions.

33
Étude de la concurrence : Différenciation par l'innovation

Pour cette analyse, nous devons non seulement observer ce que font les applications concurrentes mais
aussi identifier les caractéristiques uniques et innovantes que notre application pourrait proposer afin de se
différencier.

Approche alternative :

● Analyser les flux de réservation et d'interaction : Plutôt que de simplement examiner les
fonctionnalités de recherche ou de messagerie, il serait pertinent d'analyser la fluidité du processus
global du covoiturage dans les applications concurrentes. Cela inclut l’expérience de la réservation,
la prise en charge des urgences (modifications de dernière minute), et la gestion des annulations.

● Engagement utilisateur et rétention : Certaines plateformes utilisent des éléments de gamification


ou des récompenses pour inciter les utilisateurs à partager des trajets ou à réserver plus
fréquemment. Nous pourrions explorer cette stratégie pour encourager un usage plus actif. Cela peut
inclure un système de points pour les conducteurs ou des avantages pour les passagers réguliers.

● Exploiter les API tierces de manière créative : En plus des classiques comme Google Maps, nous
pourrions aussi intégrer des API moins courantes, par exemple, des services de planification de
trajet en fonction de l'empreinte carbone, afin de renforcer l’aspect écologique du covoiturage. Cela
pourrait vraiment différencier notre application des autres.

Analyse des risques : Approche préventive et adaptative

Plutôt que d'identifier uniquement les risques classiques, cette analyse sera axée sur la manière dont nous
pourrions anticiper les problèmes avant qu'ils ne surviennent, avec une attention particulière sur la
performance à grande échelle et l'intégration continue.

Risques à anticiper et stratégies d'atténuation :

● Impact des pannes d’API externes : Si notre application dépend d'API externes pour la
géolocalisation (comme Google Maps) ou l'envoi de notifications, nous devons envisager des
mécanismes de secours pour gérer les périodes d'indisponibilité des services tiers. L'intégration de
solutions de fallback ou de mise en cache pourrait être une solution.

● Charge serveur et montée en échelle : Si l'application connaît une forte affluence en périodes de
rentrée universitaire, nous devons nous préparer à l'escalade de la charge serveur, en optant pour
une architecture flexible basée sur des services cloud qui peuvent s’adapter au volume de trafic.
Nous devons envisager des tests de charge préalables pour valider la stabilité de l’application.

● Vie privée et sécurité des données : La sécurité des données des utilisateurs (notamment les
informations personnelles et les trajets réservés) doit être une priorité. En plus du cryptage standard,
il faut penser à des solutions de double authentification et des contrôles d'accès spécifiques pour
limiter les risques d'accès non autorisé.

34
Diagramme d'Ishikawa

Le diagramme d’Ishikawa ou diagramme en arêtes de poisson est utilisé pour explorer les causes
profondes des problèmes rencontrés dans l’application.
Exemple d’application :

Problème : Les utilisateurs trouvent difficilement des trajets adaptés.

Approche pragmatique avec la méthode des 5 pourquoi

Au lieu de seulement regrouper des causes dans des catégories générales, nous adopterons la méthode des
5 pourquoi pour creuser plus profondément dans les problèmes identifiés. Par exemple, si un problème
comme "le temps de recherche est trop long" se manifeste, nous allons interroger le système avec cinq
"pourquoi" pour trouver la cause racine, comme suit :

Problème identifié : la recherche de trajets prend trop de temps

1. Pourquoi la recherche de trajets prend-elle trop de temps ?

○ Réponse : Parce que les résultats sont souvent trop nombreux et non filtrés efficacement.

2. Pourquoi les résultats ne sont-ils pas filtrés efficacement ?

○ Réponse : Parce que les critères de recherche ne sont pas adaptés à la diversité des trajets.

3. Pourquoi les critères de recherche sont-ils inadéquats ?

○ Réponse : Parce que l’interface de recherche est trop simplifiée et ne prend pas en compte
toutes les préférences des utilisateurs.

4. Pourquoi l’interface de recherche est-elle simplifiée ?

○ Réponse : Parce que le design initial de l’application ne prévoyait pas d’options avancées
pour les utilisateurs réguliers.

35
5. Pourquoi le design initial était-il simplifié ?

○ Réponse : Parce que l’objectif initial était de rendre l’application accessible à tous, mais
cela n’a pas pris en compte la complexité des besoins des utilisateurs expérimentés.

Solution proposée :

Pour résoudre ce problème, nous proposons de réviser et enrichir les critères de recherche. Il serait
pertinent d'ajouter des filtres avancés dans l'interface, permettant aux utilisateurs de préciser leurs attentes,
comme le type de trajet (répétitif ou ponctuel), la disponibilité des places, ou la préférence pour un
conducteur. De plus, l'intégration d'un système de recommandation intelligent qui affiche des trajets en
fonction des recherches précédentes de l’utilisateur pourrait améliorer la pertinence des résultats. Nous
pouvons également introduire un moteur de recherche basé sur l'auto-apprentissage pour optimiser les
résultats au fur et à mesure des utilisations.

Cela permet non seulement d’identifier la cause profonde du problème, mais aussi de proposer une solution
concrète pour améliorer l’expérience utilisateur et rendre le système de recherche plus efficace.

36
CHAPITRE IV CREATION DE LA SOLUTION : DESIGN ET
APPROCHE STRATEGIQUE

Introduction
La phase de conception est la clé de voûte pour assurer une solution innovante et cohérente. Dans le cadre
de la gestion du covoiturage universitaire, notre objectif est de réinventer l'expérience de covoiturage,
tout en intégrant une approche intuitive, un design efficace et une architecture robuste. Cette étape est bien
plus qu'une simple formalisation technique : elle est un moteur de l'innovation dans l'utilisation des
technologies pour résoudre des défis concrets.

Définition de l'Interface Utilisateur (UI) : L’expérience Visuelle


et Intuitive

L’interface utilisateur (UI) n’est pas juste un décor, c’est l’élément central de l'interaction avec
l'application. Dans un contexte universitaire, où l’utilisateur est souvent pressé, il est crucial que l'interface
soit simple, réactive et agréable à utiliser. Nous avons repensé l'UI pour qu’elle offre une expérience
personnalisée et efficace.

● Design épuré et fonctionnel : Nous avons opté pour un design minimaliste, avec une mise en page
claire qui permet à l’utilisateur de se concentrer sur l’essentiel : trouver un trajet, réserver, et gérer
son profil. Chaque élément de l’interface sera conçu pour offrir une expérience fluide.

● Accessibilité et fluidité : L’application sera responsive, s’adaptant aussi bien aux smartphones
qu’aux tablettes et ordinateurs. En outre, elle intègrera des principes d'accessibilité, garantissant
que les utilisateurs en situation de handicap bénéficient d'une navigation optimale.

● Personnalisation du parcours utilisateur : Chaque utilisateur aura une interface qui s’adapte à
son rôle, que ce soit celui de conducteur ou de passager. Par exemple, les conducteurs auront accès
à une vue dédiée à l’organisation de leurs trajets, tandis que les passagers auront un tableau de
bord concentré sur la recherche et la gestion de leurs trajets réservés.

● Visuels et interactions dynamiques : Des animations subtiles guideront l'utilisateur tout au long
de l'expérience, facilitant l'interaction sans distraire de la tâche principale. Un glissement interactif
des trajets et une carte dynamique permettront aux utilisateurs de visualiser les options disponibles
en temps réel.

37
Architecture Technique : Structure Solide pour une Application
Évolutive

L’architecture technique est au cœur du projet, garantissant que l’application soit fiable, scalable et
sécurisée. Une attention particulière a été portée à la performance et à la sécurisation des données, en
choisissant des technologies éprouvées et adaptées.

● Back-end moderne et performant : Nous avons opté pour Spring Boot, une technologie éprouvée
pour la création d'APIs RESTful scalables. Le traitement asynchrone des tâches permettra de gérer
efficacement les demandes des utilisateurs, notamment lors de la recherche de trajets ou de la mise
à jour des réservations.

● Base de données relationnelle optimisée : MySQL a été choisi pour sa robustesse et sa capacité à
gérer efficacement les données structurées liées aux trajets, utilisateurs et réservations. Une gestion
géospatiale des trajets pourra être intégrée, pour offrir une recherche optimisée des trajets en
fonction de la proximité géographique.

● Front-end réactif et dynamique : Le choix de Angular permettra de créer une interface dynamique
et réactive, avec un forte capacité d’interaction en temps réel (réservation instantanée, affichage de
trajets sur la carte). Le framework Angular assure également une maintenance aisée à long terme
grâce à sa structure modulaire.

● Sécurisation de l’application : Spring Security et l’utilisation de JWT (JSON Web Tokens)


garantiront la gestion des sessions et des permissions de manière sécurisée. La confidentialité des
informations personnelles sera assurée par une conformité stricte aux normes RGPD.

Expérience Utilisateur : Une Navigation Optimale et


Satisfaisante

L'UX, ou expérience utilisateur, se veut centrée sur l'efficacité et la simplicité. Chaque utilisateur, qu'il
soit conducteur ou passager, doit trouver la solution idéale pour ses besoins de manière intuitive et rapide.
L'objectif est de rendre l'interaction avec l'application naturelle, sans effort, en supprimant toute barrière
d'utilisation.

● Navigation simplifiée et rapide : Nous avons conçu un parcours utilisateur fluide, permettant
d’accéder en moins de trois clics aux fonctionnalités principales : réserver un trajet, consulter son
historique, ou gérer son profil. Le processus de réservation, par exemple, sera simple et intuitif, avec
des étapes clairement définies

● Feedback en temps réel : Chaque action réalisée par l’utilisateur sera suivie d’une notification
visuelle immédiate, que ce soit pour confirmer une réservation, un paiement ou l’ajout d’un
nouveau trajet. Cela permet de renforcer la confiance de l’utilisateur dans l’application.

38
● Tests utilisateurs et itérations : Afin de valider chaque décision prise lors de la conception, nous
ferons des tests utilisateurs réguliers, permettant de recueillir des retours concrets et de réaliser
des ajustements. Des prototypes interactifs seront créés et ajustés en fonction des feedbacks reçus.

● Optimisation continue : L’application sera constamment améliorée pour correspondre au mieux


aux attentes des utilisateurs. Des mises à jour régulières apporteront de nouvelles fonctionnalités
ou amélioreront l'interface existante en fonction des retours.

Prototype et Validation : Valider Avant de Passer à l’Action

Un prototype interactif sera créé pour tester les concepts de l’interface et la navigation. Ce prototype servira
à simuler des parcours réels, permettant aux utilisateurs de tester l’application avant son lancement. Les
retours obtenus permettront de valider ou d’ajuster les choix de design et de parcours.

● Validation par les utilisateurs : Des sessions de tests seront organisées avec un panel d’utilisateurs,
principalement composé d'étudiants et de conducteurs, pour garantir que l’application répond
réellement aux besoins du terrain. Le prototype permettra également de tester des cas d’utilisation
en conditions réelles.

● Préparation pour le développement : Une fois validé, le prototype servira de référence pour le
développement. Les équipes de développement disposeront d’un plan détaillé pour débuter la phase
de programmation, en assurant une transposition fidèle du design et des interactions validées.

39
Diagramme des classes :

40
CHAPITRE V VERIFICATION (VERIFY) : VALIDATION DES
RESULTATS

Introduction
La phase de vérification constitue une étape cruciale dans le cycle de vie du projet. Elle vise à valider la
conformité du produit final aux normes de qualité définies, en l’occurrence la norme ISO/IEC 25010. Cette
norme nous a servi de cadre pour établir des critères d'évaluation objectifs et détaillés couvrant les huit
caractéristiques principales et leurs sous-caractéristiques.

Pour garantir la fiabilité des résultats, des tests rigoureux ont été réalisés en utilisant des outils modernes,
des méthodologies adaptées, et des scénarios basés sur des cas d’utilisation réels. Les données collectées
sont analysées pour mesurer dans quelle mesure l'application répond aux attentes des utilisateurs tout en
respectant les exigences fonctionnelles et non fonctionnelles.

Adéquation fonctionnelle
V. 2. 1 Méthodologie
Les tests ont été réalisés en suivant les étapes suivantes :

1. Identification des fonctionnalités à tester.


2. Création de scénarios de test basés sur les cas d’utilisation.
3. Exécution des tests avec différentes données (valides, invalides, limites).
4. Évaluation des résultats obtenus.
Outils utilisés :

• Navigateur pour tester l'interface utilisateur.


• Postman pour vérifier les API et les données échangées avec le backend.
• Tableau pour documenter les résultats des tests.

V. 2. 2 Résultats des Tests

Complétude Fonctionnelle

Objectif : Vérifier si toutes les fonctionnalités nécessaires sont présentes.

41
Fonctionnalité Statut Observations
Création de trajets Fonctionnelle L’utilisateur peut créer un trajet avec des données valides.
Réservation de trajets Fonctionnelle La réservation fonctionne correctement avec un retour
utilisateur clair.
Consultation des Fonctionnelle Les réservations associées à un trajet sont affichées sans
réservations erreurs.
Notifications En cours La fonctionnalité est en développement et non testée dans
ce rapport.
Conclusion : Toutes les fonctionnalités majeures sont implémentées, à l'exception des notifications.

Création de trajets 1

Consultation des réservations

42
Réservation des trajets

Correction Fonctionnelle

Objectif : Vérifier que chaque fonctionnalité fonctionne correctement sans erreur.

Scénario Données d’entrée Résultat attendu Résultat obtenu Statut

Création d’un trajet Données valides Trajet créé avec succès Trajet créé Succès

Données invalides Message d’erreur


Création d’un trajet Message d’erreur affiché Succès
(vide) affiché

Affichage des Liste des réservations


Trajet existant Liste correcte Succès
réservations affichée

En
Notification Nouvelle réservation Notification visible Non applicable
cours

Conclusion : Les fonctionnalités implémentées fonctionnent correctement et répondent aux attentes. Les
notifications nécessitent une finalisation pour être testées.

43
Création d’un trajet données validée

Création d’un trajet données invalide

Pertinence Fonctionnelle

Objectif : Vérifier que les fonctionnalités répondent aux besoins des utilisateurs.

A. Analyse des Besoins

Les besoins des utilisateurs ont été identifiés comme suit :

• Création de trajets : Doit être rapide et intuitive.


• Réservation : Recherche simple et options de réservation efficaces.
• Notifications : Les utilisateurs doivent être informés des actions (acceptation/rejet de réservation).
B. Retours Utilisateurs

Des tests utilisateurs ont été réalisés avec un groupe restreint. Les observations sont les suivantes :

• Points positifs :

44
o Interface intuitive pour la création de trajets.
o Fonction de recherche des trajets efficace.
• Points à améliorer :
o Les utilisateurs attendent des notifications pour être informés des changements.
Conclusion : Les fonctionnalités existantes sont pertinentes, mais l’ajout de notifications améliorera
l’expérience utilisateur.

V. 2. 3 Problèmes Identifiés et Recommandations


Problème Impact Recommandation

Notifications non Les utilisateurs ne sont pas Finaliser le développement et tester les
fonctionnelles informés notifications.

Validation des données Ajouter des validations côté client pour une
Risque d'erreur utilisateur
(front-end) meilleure UX.

Fiabilité
Outil Utilisé : Sentry

Pour garantir la fiabilité de notre application, nous avons utilisé Sentry, un outil performant de supervision
en temps réel. Cet outil nous a permis de surveiller l'application de manière proactive et d'identifier
rapidement les erreurs et anomalies, tout en assurant une disponibilité optimale.

Les points clés de la fiabilité évalués à l’aide de Sentry sont les suivants :

1. Maturité :
o Description : Identification proactive des erreurs critiques et des anomalies avant qu'elles
n'affectent les utilisateurs.
o Résultat : Un tableau de bord détaillé nous a permis de suivre et de corriger les anomalies
en temps réel.

45
2. Disponibilité :
o Description : Surveillance continue des performances pour garantir un uptime élevé, même
en cas de forte charge ou de trafic inattendu.
o Résultat : Maintien d'un temps de fonctionnement supérieur à 99 % grâce à des alertes en
temps réel.

3. Tolérance aux fautes :


o Description : Implémentation de mécanismes permettant de limiter l'impact des défaillances
mineures.
o Résultat : L'application a pu se rétablir automatiquement lors d'erreurs non critiques.

46
4. Capacité de récupération (MTTR) :
o Description : Réduction du temps moyen de réparation grâce aux alertes instantanées de
Sentry.
o Résultat : Réaction rapide aux incidents, avec une diminution significative des interruptions
de service.

Performance et efficacité
Dans le cadre de l'évaluation des performances de notre application, des tests de performance ont été réalisés
à l’aide de l’outil Apache JMeter. Ces tests se concentrent sur deux API principales, GetAvailableRoutes
et getRouteInformations, en simulant 1000 requêtes pour évaluer les temps de réponse, la latence, et
l’utilisation des ressources.

47
V. 4. 1 Performances Serveur

GetAvailableRoutes

• Résultats des Tests de Performance

o Temps de réponse moyen : 7 ms


o Latence moyenne : 7 ms
o Temps d’établissement de la connexion : 0 ms
o Taille moyenne de la réponse : 1083 octets
o Taille moyenne de l’en-tête : 421 octets
o Taille moyenne du corps de réponse : 662 octets
o Octets envoyés par requête : 148 octets
o Code de retour : 200 (succès)
o Taux d’erreur : 0 %

48
API getRouteInformations

• Résultats des Tests de Performance


o Temps de réponse moyen : 7 ms
o Latence moyenne : 7 ms
o Temps d’établissement de la connexion : 0 ms
o Taille moyenne de la réponse : 1083 octets
o Taille moyenne de l’en-tête : 421 octets
o Taille moyenne du corps de réponse : 662 octets
o Octets envoyés par requête : 148 octets
o Code de retour : 200 (succès)
o Taux d’erreur : 0 %

49
Comparaison des Résultats avec les Objectifs

Objectifs définis

1. Comportement temporel :
o Temps moyen de réponse acceptable pour les API : Défini par la norme comme idéalement
< 200 ms.
o Charge de test : 1000 requêtes avec une charge variable (10 à 500 utilisateurs simultanés).
2. Capacité :
o Évaluer le nombre maximal de requêtes supportées par seconde avant d'atteindre un taux
d’erreur de 5 %.

Analyse Comparative

1. Comportement temporel :
o Observation : Avec un temps moyen de réponse de 7 ms et une latence équivalente, les
performances de l’API sont nettement en dessous de la limite acceptable (200 ms). Ces
résultats indiquent une excellente optimisation du traitement des requêtes pour une charge
modérée de 100 requêtes.
o Écart : Les tests actuels ont été réalisés sur 1000 requêtes, alors que l’objectif visait une
moyenne calculée sur 5000 requêtes avec des scénarios de charge variables. Les résultats
restent prometteurs mais nécessitent des tests à plus grande échelle.
2. Capacité :
o Observation : Le test a démontré une capacité à gérer 1000 requêtes sans erreur (taux
d’erreur : 0 %). Cependant, les objectifs définissent un scénario croissant allant jusqu’à 5000
requêtes/s pour identifier la limite de charge.
o Écart : Le seuil maximal de requêtes par seconde et la robustesse sous forte charge n’ont
pas encore été pleinement explorés.

Synthèse

• Points positifs :
o Les performances actuelles des API testés sont excellentes pour une charge modérée.
o Les résultats sont bien en ligne avec les objectifs de rapidité et de fiabilité pour un scénario
de 1000 requêtes.

50
• Recommandations :
o Étendre les tests pour atteindre la charge définie dans les objectifs (5000 requêtes, avec des
utilisateurs simultanés).
o Réaliser des tests de capacité pour déterminer le nombre maximal de requêtes supportées
par seconde tout en respectant un taux d’erreur inférieur à 5 %.

Les résultats actuels constituent une base solide pour les performances de l’API, mais des tests
supplémentaires sont nécessaires pour valider sa robustesse sous des charges plus élevées.

V. 4. 2 Performances Client

Pour évaluer la performance de l’interface utilisateur, nous avons utilisé Lighthouse, un outil open-source
de Google intégré au navigateur Chrome. Lighthouse permet de mesurer différents aspects de la
performance d'une application web, notamment le temps de chargement, la réactivité, et l’efficacité des
ressources. Il fournit un score global basé sur des métriques clés comme First Contentful Paint (FCP),
Speed Index, et Time to Interactive (TTI).

logo Lighthouse Report

Résultats :

51
• Score de performance global : 66 %
• Les métriques clés identifiées incluent :
o First Contentful Paint (FCP) : Indique le moment où le premier contenu est visible, jugé
satisfaisant.
o Time to Interactive (TTI) : Temps nécessaire pour que la page devienne entièrement
interactive, jugé modéré.
o Opportunités d’amélioration : Réduction de la taille des images et optimisation des
ressources JavaScript.

Interprétation

Un score de 66 % reflète une performance moyenne, suffisante pour une utilisation courante, mais avec
des opportunités d’optimisation. Les principaux axes d'amélioration identifiés concernent :

1. Optimisation des ressources : Réduction des scripts JavaScript volumineux et limitation des CSS
inutilisés.
2. Compression d'images : Les images non optimisées ralentissent le chargement de la page.
3. Mise en cache : Amélioration des stratégies de mise en cache pour réduire les temps de
rechargement.

Conclusion

Bien que le score soit acceptable pour une version initiale, des améliorations ciblées peuvent augmenter
significativement la performance front-end et offrir une expérience utilisateur plus fluide. L’intégration
continue de Lighthouse dans le pipeline de développement permettra de surveiller et d’optimiser les
performances au fil du temps.

Sécurité

La sécurité est une priorité dans le développement de notre application. Nous avons implémenté plusieurs
mécanismes pour garantir la protection des données et la gestion sécurisée des accès utilisateurs. Ces
mécanismes incluent l'utilisation de JWT (JSON Web Tokens), la gestion des rôles, et la mise en place
d'une logique robuste pour le rafraîchissement des tokens et la déconnexion. Ces approches assurent une
expérience utilisateur fluide tout en protégeant l'application contre les menaces potentielles.

52
V. 5. 1 Implémentation de JWT (JSON Web Tokens)

• Description : Les JWT sont utilisés pour authentifier les utilisateurs et sécuriser les sessions.
Chaque utilisateur authentifié reçoit un token signé qui est utilisé pour accéder aux ressources
protégées de l'application.
• Avantages :
o Sécurisation des sessions sans besoin de stocker les identifiants sur le serveur.
o Token léger, facile à transmettre dans les en-têtes HTTP.
• Fonctionnalité :
o Génération de tokens au moment de l'authentification.
o Validation des tokens pour chaque requête.

V. 5. 2 Logique de Rafraîchissement du Token

• Description : Une logique de rafraîchissement de token a été implémentée pour prolonger la session
utilisateur sans nécessiter une reconnexion fréquente.
• Avantages :
o Réduction des interruptions pour l'utilisateur.
o Maintien d’un haut niveau de sécurité en renouvelant périodiquement les tokens.
• Fonctionnalité :
o Le token principal a une durée de vie courte (ex. : 15 minutes).
o Un refresh token avec une durée de vie plus longue permet de générer un nouveau token
principal.

53
V. 5. 3 Logique de Déconnexion (LogOut)

• Description : Une fonctionnalité de déconnexion sécurisée a été ajoutée pour garantir qu’aucun
token ne reste valide après que l’utilisateur se déconnecte.
• Fonctionnalité :
o Avant la déconnexion, il est vérifié que les tokens d'accès et de rafraîchissement sont non
expirés et non révoqués, assurant ainsi une session valide.

o Lors de la déconnexion :

54
▪ Le token principal et le refresh token associés sont immédiatement marqués comme
révoqués.
▪ Ces tokens sont invalidés côté serveur pour empêcher toute utilisation future, même
s’ils sont encore techniquement valides.

Gestion des Accès par Rôle

• Description : Les ressources de l'application sont protégées par une logique d'accès basée sur les
rôles utilisateur (par ex. : ADMIN, PASSENGER, DRIVER).
• Avantages :
o Contrôle granulaire des permissions.
o Réduction des risques d’accès non autorisé.
• Fonctionnalité :
o Chaque requête est vérifiée par le serveur pour s’assurer que l’utilisateur a les autorisations
nécessaires.
o Par exemple, l'API getAllUsers, qui retourne la liste de tous les utilisateurs, est
accessible uniquement aux administrateurs. Voici un des captures du test :

User1 : ADMIN

User2 : PASSENGER

55
Tentative d’utiliser l’API getAllUsers par User2 (cas d’échec) :

56
Tentative d’utiliser l’API getAllUsers par User1 (cas de sucées) :

o Dans cet exemple, seuls les utilisateurs avec le rôle "ADMIN" peuvent accéder à l'API
getAllUsers. Si un utilisateur sans ce rôle tente d’y accéder, l’accès sera refusé avec une
erreur d’autorisation (HTTP 403).

57
Résultats et Bénéfices

L’implémentation de ces mécanismes de sécurité garantit :

1. Protection des données : Les tokens JWT réduisent les risques d’usurpation d’identité grâce à une
signature sécurisée.
2. Contrôle d’accès renforcé : La gestion des rôles limite les actions que chaque utilisateur peut
effectuer.
3. Expérience utilisateur fluide : La logique de rafraîchissement minimise les interruptions tout en
maintenant un haut niveau de sécurité.
4. Prévention des failles courantes : Les attaques comme le CSRF (Cross-Site Request Forgery) est
efficacement atténuées.

Conclusion

Ces mécanismes de sécurité assurent une application robuste, alignée avec les meilleures pratiques en
matière de protection des données et d'authentification des utilisateurs. À l’avenir, des audits réguliers de
sécurité seront effectués pour renforcer davantage la protection contre les nouvelles menaces.

58
CONCLUSION GENERALE

Le projet de développement d’une application de gestion de covoiturage universitaire illustre comment une
méthodologie structurée, comme DMADV, peut transformer un défi concret en une solution innovante et
durable. En nous appuyant sur une analyse approfondie des besoins des utilisateurs et sur des choix
technologiques stratégiques, nous avons conçu une application qui répond aux attentes des étudiants,
enseignants et personnels universitaires, tout en contribuant à une réduction significative de l'empreinte
carbone des déplacements.

Ce rapport a démontré l'importance de chaque étape du processus de développement, depuis la définition


des besoins fonctionnels et qualitatifs, jusqu’à la validation des résultats. À travers des outils modernes tels
que Spring Boot, Angular, et des standards de qualité comme la norme ISO/IEC 25010, nous avons
garanti que l’application soit performante, intuitive, et surtout adaptée à son public cible.

Au-delà des aspects techniques, ce projet met également en lumière des valeurs fondamentales, telles que
la collaboration et l’écoresponsabilité. L’adoption du covoiturage universitaire ne se limite pas à un simple
gain pratique : elle crée un impact positif en renforçant les liens au sein de la communauté universitaire et
en favorisant une culture de partage et d’entraide. Cette initiative s'inscrit dans une démarche plus large
visant à proposer des solutions numériques respectueuses de l'environnement et orientées vers les besoins
actuels.

Cependant, tout projet comporte des marges d’amélioration et des perspectives d’évolution. À l’avenir, des
itérations basées sur les retours d’expérience des utilisateurs permettront d’affiner l’expérience utilisateur
et d’introduire de nouvelles fonctionnalités, comme l’intégration de services tiers ou l’ajout de mécanismes
de gamification pour stimuler l’engagement. De même, une extension du système à d’autres institutions ou
contextes pourrait accroître son impact.

En conclusion, ce projet illustre comment une vision claire, soutenue par une approche méthodique et des
outils performants, peut répondre aux enjeux contemporains. L’application de gestion de covoiturage
universitaire, en alliant innovation, qualité et responsabilité écologique, a le potentiel de devenir une
référence pour les solutions de mobilité durable au sein des campus.

59

Vous aimerez peut-être aussi