Rapport Finale DMADV de SsEq1.2
Rapport Finale DMADV de SsEq1.2
RAPPORT DMADV
Sujet
Développement d’une application de Gestion de Covoiturage
Universitaire
INTRODUCTION GENERALE............................................................................................1
Introduction ...................................................................................................................... 2
II. 8. 2 Spécification des métriques pour chaque caractéristique (avec des règles
supplémentaires pour la mesure) ...................................................................................... 19
Introduction ................................................................................................................. 33
Introduction ................................................................................................................. 37
Introduction .................................................................................................................. 41
V. 2. 1 Méthodologie ........................................................................................................ 41
Fiabilité......................................................................................................................... 45
V. 4. 2 Performances Client.............................................................................................. 51
Sécurité ......................................................................................................................... 52
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.
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 ?)
● 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.
2
5. Approche Technologique (Comment ?)
● 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.
Le développement de cette application répond à des besoins spécifiques et offre des avantages clairs :
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 :
1. Questions fermées :
• 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 :
• Enquête ciblée pour comprendre ce qui encouragerait les utilisateurs à proposer des
trajets.
• Identifier les heures et les trajets les plus fréquents pour optimiser l'offre.
4
4. Enquête sur les freins à l'adoption :
Questionnaire proposé :
5
Synthèse des résultats :
6
1. Quelle utilisation ferez-vous principalement de l'application ?
7
Section 2 : Attentes Fonctionnelles
8
• Conclusion : La rapidité de l'application est essentielle pour assurer une bonne
expérience utilisateur.
2. Préférence de notifications :
9
• Conclusion : Une interface simple et ergonomique est cruciale pour l'adoption de
l'application.
5. Propositions d'Actions
● Mettre en place un système de récompenses pour les conducteurs (ex : bons d'achat, points
cumulables).
10
● Créer des tutoriels et guides pour les nouveaux utilisateurs.
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.
● 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.
● 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.
La sécurité, au cœur de notre application, nécessite un suivi continu et une adaptation à chaque itération du
projet.
○ 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.
○ 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.
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.
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 :
L’objectif est de créer une boucle de rétroaction constante pour une adaptation instantanée aux besoins des
utilisateurs.
○ 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.
14
Engagement et adoption : suivi de l’évolution des utilisateurs
Pour mesurer la satisfaction et répondre aux attentes des utilisateurs, nous avons défini les KPIs suivants :
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.
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.
1. Adéquation fonctionnelle :
○ Sous-caractéristiques :
2. Fiabilité :
○ Sous-caractéristiques :
16
■ Disponibilité : Maintenir un taux d’uptime élevé (> 99%).
■ Tolérance aux fautes : L’application doit continuer à fonctionner malgré des erreurs
mineures.
3. Performance et efficacité :
○ Sous-caractéristiques :
4. Compatibilité :
○ Sous-caractéristiques :
5. Sécurité :
○ Sous-caractéristiques :
6. Maintenabilité :
17
○ Faciliter les modifications et mises à jour.
○ Sous-caractéristiques :
7. Utilisabilité :
○ Sous-caractéristiques :
8. Portabilité :
○ Sous-caractéristiques :
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 :
○ Règle de mesure :
● Correction fonctionnelle :
○ Règle de mesure :
● Pertinence fonctionnelle :
○ Règle de mesure :
2. Fiabilité
19
● Disponibilité :
○ Règle de mesure :
■ Utiliser un outil de monitoring (ex. : New Relic) pour mesurer le temps total
d'indisponibilité.
■ Calculer :
● Maturité :
○ Règle de mesure :
■ Considérer uniquement les bugs classés comme critiques ou majeurs dans un outil
de suivi (ex. : Jira).
○ Règle de mesure :
■ Simuler des scénarios d’erreur (ex. : coupure réseau, requêtes mal formées).
● Capacité de récupération :
○ Règle de mesure :
20
3. Performance et efficacité
● Comportement temporel :
○ 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é :
○ Règle de mesure :
4. Compatibilité
● Coexistence :
○ Règle de mesure :
■ Tester l’intégration avec au moins 3 services tiers (ex. : Google Maps, Firebase).
● Interopérabilité :
○ 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é :
○ Règle de mesure :
● Authentification :
○ Règle de mesure :
■ Vérifier que 100% des connexions passent par un protocole sécurisé (ex. : HTTPS).
6. Maintenabilité
● Testabilité :
○ Règle de mesure :
● Modifiabilité :
○ Règle de mesure :
7. Utilisabilité
22
● Appréhensibilité :
○ Règle de mesure :
● Esthétique :
○ Règle de mesure :
8. Portabilité
● Adaptabilité :
○ Règle de mesure :
● Installabilité :
○ Règle de mesure :
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.
● 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.
Type de test
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/
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.
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é
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.
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/
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)
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.
○ 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).
○ 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
○ 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.
○ Utiliser Flutter (ou d'autres frameworks) pour son efficacité dans la gestion des ressources et son
approche multiplateforme.
○ 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.
○ 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.
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.
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é.
● 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.
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.
● 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.
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.
● 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 :
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 :
○ Réponse : Parce que les résultats sont souvent trop nombreux et non filtrés efficacement.
○ Réponse : Parce que les critères de recherche ne sont pas adaptés à la diversité des trajets.
○ 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.
○ 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.
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.
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.
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 :
Complétude Fonctionnelle
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
42
Réservation des trajets
Correction Fonctionnelle
Création d’un trajet Données valides Trajet créé avec succès Trajet créé Succès
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
Pertinence Fonctionnelle
Objectif : Vérifier que les fonctionnalités répondent aux besoins des 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.
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.
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
48
API getRouteInformations
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).
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.
• 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.
• 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
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.
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