BUS ROUTE

Presentation du projet

Le « projet DTC » est une application mobile qui aide les gens à trouver les
lignes de bus jusqu'à leur destination souhaitée et le tarif.

Le système du projet DTC est composé de deux composants principaux : une

application côté client qui fonctionnera sur les téléphones Android et une
application côté serveur qui prendra en charge et interagira avec les
requêtes côté client.

Les utilisateurs propriétaires fournissent leurs informations de destination à

l'aide du portail Web.

Le portail Web vérifie les connexions en tant que passager ou administrateur

et gère les informations utilisateur. Les données seront conservées dans une
base de données Access sur le serveur DTC.

Un administrateur de DTC se connecte pour télécharger des informations sur

les lignes de bus ou créer une nouvelle entrée de base de données, mettre à
jour une entrée de base de données existante ou gérer les plaintes et
requêtes formulées par les passagers.

L'application doit être téléchargeable gratuitement à partir d'un magasin

d'applications pour téléphone mobile ou de services similaires

Perspective du produit

Toutes les informations du système sont conservées dans une base de

données, qui se trouve sur un serveur Web. Cela comprend les informations
sur les utilisateurs et les administrateurs ainsi que les informations sur les
bus, c'est-à-dire leurs itinéraires et leurs tarifs.

Une connexion Internet est nécessaire pour accéder au système, pour

récupérer et afficher les résultats et pour s'inscrire et se connecter.

Comme il s'agit d'un produit centré sur les données, il faudra un endroit pour
stocker les données.

Pour cela, une base de données sera utilisée. L'application mobile et le portail
Web communiqueront avec la base de données, mais de manière légèrement
différente.
L'application mobile utilisera uniquement la base de données pour obtenir
des données tandis que le portail Web ajoutera et modifiera également des
données.

Toutes les communications de la base de données passeront par Internet.

L'application mobile a certaines restrictions concernant l'allocation des

ressources. Pour éviter les problèmes de surcharge du système
d'exploitation, l'application n'est autorisée à utiliser que 20 mégaoctets de
mémoire lors de l'exécution de l'application.

La quantité maximale d'espace disque dur est également de 20 mégaoctets.

CAHIER DE CHARGE

Cahier des Charges - Système de Consultation des

Itinéraires de Bus

1. Introduction

Ce document spécifie le projet pour développer une application mobile et un

portail web permettant aux utilisateurs de :

 Consulter les itinéraires des bus, les tarifs et les horaires.

 Gérer les données des itinéraires de bus pour l'administration.

Le produit est conçu pour le Transport Corporation et vise à simplifier la

gestion et l'accès aux informations des transports publics.

1. Contexte et Justification
Le projet City Bus s'inscrit dans une démarche de transformation
numérique des services de transport public. Il vise à résoudre
plusieurs problématiques rencontrées par les passagers et les
administrateurs, tout en modernisant la gestion des données et des
interactions avec les usagers.

Défis actuels des passagers :

 1. Manque d'informations centralisées :
Les usagers doivent souvent se fier à des supports physiques
(horaires imprimés, panneaux) ou à des informations verbales,
souvent obsolètes ou peu accessibles.
2. Difficulté à trouver des itinéraires adaptés :
Sans outil numérique, la recherche des trajets entre un point
de départ et une destination implique des étapes longues et
peu intuitives.
3. Absence de retours sur les changements d'itinéraires :
Les passagers ne sont pas informés efficacement des
modifications d'horaires, des perturbations ou des annulations.
4. Absence de gestion centralisée des requêtes et plaintes :
Les passagers n'ont pas de moyen simple pour soumettre leurs
requêtes ou signaler des problèmes, ce qui limite les retours
d'expérience pour l'amélioration du service.

Défis pour les administrateurs :

1. Gestion manuelle des itinéraires et données :
Les données sur les lignes de bus, les horaires et les tarifs sont
souvent mises à jour manuellement, ce qui peut entraîner des
erreurs et des retards.
2. Réception et traitement des plaintes :
L'absence de plateforme centralisée rend difficile le suivi des
plaintes et des requêtes des passagers, créant des frustrations
et limitant l’efficacité des réponses.
3. Suivi limité des performances :
Sans un système numérique, il est compliqué de collecter et
d'analyser les données relatives à l’utilisation des bus et à la
satisfaction des passagers.

Bénéfices attendus avec le projet :

Pour les passagers :
 Accès simplifié et instantané aux informations essentielles :
horaires, tarifs, itinéraires.
 Possibilité de trouver rapidement les trajets les plus adaptés à
leurs besoins.
  Réduction de l'incertitude grâce à des notifications en cas de
changements d'itinéraires.
 Une voie de communication directe pour transmettre des
requêtes et signaler des problèmes.
Pour les administrateurs :
 Automatisation et centralisation des mises à jour des données
sur les trajets et horaires.
 Outils de suivi pour répondre efficacement aux plaintes et
améliorer le service.
 Réduction des erreurs humaines grâce à un système de gestion
numérique fiable.
 Meilleure analyse des données (ex. : itinéraires les plus
empruntés) pour optimiser l’offre de transport.

2. Objectifs du Projet

1. Améliorer l'accès à l'information pour les passagers :

a. Trouver facilement les itinéraires et tarifs des bus pour leur
destination.
2. Faciliter la gestion pour l'administration :
a. Mettre à jour et consulter les informations sur les itinéraires des
bus via un portail sécurisé.
3. Optimiser l'expérience utilisateur :
a. Offrir une application intuitive et un service en ligne fiable.
2. Analyse des Parties Prenantes
La réussite du projet City Bus repose sur une compréhension
approfondie des parties prenantes et de leurs besoins spécifiques.
Cette section identifie les utilisateurs finaux et les organisations
impliquées tout en intégrant leurs attentes pour garantir que le
système réponde efficacement aux objectifs et aux exigences.

2.1. Identification des parties prenantes

Les parties prenantes du projet se divisent en deux grandes
catégories :
 1. Utilisateurs finaux :
o Passagers : Les citoyens ou usagers réguliers des
transports publics.
o Administrateurs : Les responsables techniques et
opérationnels des sociétés de transport.
2. Parties prenantes organisationnelles :
o Municipalités : Autorités locales responsables de
l’organisation des services de transport.
o Sociétés de transport public : Opérateurs en charge de la
gestion quotidienne des lignes de bus.

2.2. Besoins spécifiques des parties prenantes

2.2.1. Passagers :
Les passagers sont les utilisateurs primaires de l’application mobile.
Ils ont besoin de :
 Accès à des informations fiables et à jour :
Ils souhaitent consulter rapidement les itinéraires, horaires et
tarifs des bus pour planifier efficacement leurs déplacements.
 Simplicité d'utilisation :
Une interface intuitive est essentielle, car tous les utilisateurs
ne maîtrisent pas nécessairement les outils numériques.
 Réactivité aux changements :
Les passagers doivent être informés immédiatement des
perturbations ou modifications d’itinéraires via des
notifications en temps réel.
 Un moyen de communication direct :
L'application doit leur permettre de soumettre des requêtes ou
plaintes pour signaler des problèmes ou partager leurs retours.
Exemple de besoin concret :
Un passager doit pouvoir trouver un bus pour se rendre à un lieu
donné en moins de 10 secondes, avec des informations détaillées
sur le trajet.

2.2.2. Administrateurs :
Les administrateurs gèrent les données et assurent la maintenance
opérationnelle du système via le portail web. Leurs besoins
incluent :
 Gestion centralisée des informations :
Une interface pour ajouter, modifier, ou supprimer les
itinéraires, les horaires et les tarifs sans duplicata ou
incohérences.
 Suivi des plaintes et requêtes :
Une plateforme dédiée pour consulter, prioriser et répondre
rapidement aux retours des passagers.
 Analyse des données :
Ils doivent pouvoir exploiter les données (fréquentation des
trajets, requêtes fréquentes) pour améliorer les services et
ajuster les itinéraires en fonction des besoins réels.
Exemple de besoin concret :
Un administrateur doit pouvoir mettre à jour un horaire ou un tarif
dans la base de données en moins de 2 minutes, et ces informations
doivent être instantanément disponibles pour les passagers.

2.2.3. Municipalités :
Les municipalités supervisent l'organisation des transports publics.
Elles attendent du projet :
 Amélioration de l’accessibilité :
Le système doit permettre aux citoyens d’accéder facilement
aux transports en commun, en réduisant les obstacles liés à
l'information.
 Efficacité opérationnelle :
Une gestion numérique centralisée qui réduit les coûts
opérationnels et améliore la qualité du service.
 Conformité aux réglementations :
L’application doit respecter les standards de sécurité des
données et d’accessibilité (par exemple, pour les personnes en
situation de handicap).

2.2.4. Sociétés de transport public :

Les opérateurs qui gèrent les lignes de bus souhaitent :
  Optimisation des ressources :
Planifier les trajets et ajuster les itinéraires selon les besoins
des usagers en se basant sur des analyses de données
précises.
 Réduction des plaintes :
En répondant rapidement et efficacement aux requêtes, ils
cherchent à améliorer la satisfaction des usagers.
 Augmentation de la fréquentation :
En rendant les transports publics plus accessibles et pratiques,
ils espèrent attirer davantage d’utilisateurs.

2.3. Intégration des attentes des parties prenantes

Pour répondre aux attentes des parties prenantes, le projet City Bus
intègre des fonctionnalités et des approches spécifiques :
1. Approche centrée sur les utilisateurs finaux :
o Interface mobile intuitive et facile à utiliser.
o Système de notification intégré pour informer les
passagers en temps réel.
o Recherche d’itinéraires rapide avec des résultats clairs.
2. Outils dédiés pour les administrateurs :
o Tableau de bord interactif pour la gestion des données et
des plaintes.
o Visualisation des performances (tableaux, graphiques)
pour une prise de décision basée sur les données.
3. Collaboration avec les municipalités et sociétés de transport :
o Respect des politiques locales et des réglementations de
transport.
Réalisation de rapports périodiques sur l’utilisation des lignes de
bus et les retours des usagers.

3. Fonctionnalités Principales

Pour les utilisateurs :

  Recherche des itinéraires selon le point de départ et de destination.
 Affichage des tarifs et des numéros de bus.
 Enregistrement et connexion sécurisés.
 Soumission des requêtes et plaintes.

Pour les administrateurs :

 Gestion des itinéraires des bus (ajout, modification, suppression).

 Consultation et traitement des requêtes et plaintes des utilisateurs.

4. Description Technique

 Environnement :
o Application mobile compatible Android (5.0 et versions
ultérieures).
o Portail web accessible via les navigateurs courants.
o Serveur hébergé sur Linux avec base de données MySQL.
 Contraintes :
o Limitation à 20 Mo de mémoire pour l'application mobile.
o Temps de chargement des pages web inférieur à 5 secondes.

5. Modules

1. Inscription et Connexion :
a. Inscription des utilisateurs avec des informations personnelles.
 Collecte des informations personnelles : nom, e-mail, numéro de
téléphone (facultatif), et mot de passe.
 Validation des données saisies pour éviter les doublons et garantir leur
exactitude.
 Création d'un identifiant unique pour chaque utilisateur dans la base de
données.

b. Connexion sécurisée avec vérification des identifiants.

 Vérification des identifiants fournis (e-mail/nom d'utilisateur et mot de
passe).
 Utilisation de protocoles sécurisés (HTTPS) pour la transmission des
données de connexion.
  Déconnexion automatique après une période d'inactivité pour protéger
les comptes utilisateurs.

2. Recherche d'itinéraires :
a. Interface intuitive pour saisir les points de départ et d'arrivée.
 Champs pour saisir les points de départ et d'arrivée.
 Suggestions automatiques basées sur les données disponibles dans la
base de données

b. Résultats incluant les numéros de bus et les tarifs.

 Affichage des numéros de bus, des itinéraires, et des tarifs associés.
 Indication des itinéraires alternatifs si disponible.
 Message d'erreur clair si aucun itinéraire ne correspond à la requête.

3. Gestion Administrative :
a. Tableau de bord pour ajouter, modifier et supprimer des
itinéraires.
 Affichage des données actuelles des itinéraires de bus, incluant les
numéros, tarifs, et trajets.
 Fonctions pour ajouter, modifier, ou supprimer des itinéraires via un
formulaire interactif.
 Historique des modifications pour assurer la traçabilité.

b. Consultation des requêtes et plaintes des passagers.

 Consultation des plaintes soumises par les utilisateurs.
 Réponse directe via l'interface administrative ou exportation des
requêtes pour un traitement externe.
 Statut de suivi pour informer les passagers (en cours, résolu, etc.).

4. Enrichissement de la Partie Technique

Cette section propose un approfondissement technique structuré pour le
projet City Bus avec des diagrammes UML détaillés, une description de
l'architecture en couches, et des exemples concrets de code pour illustrer les
principales fonctionnalités.

4.1. Diagrammes UML

a. Diagramme de cas d’utilisation
Ce diagramme représente les interactions principales entre les acteurs et le
système City Bus.
1. Acteurs principaux :
o Passager : Consulter les itinéraires, tarifs et horaires, soumettre
des plaintes, et recevoir des notifications.
o Administrateur : Gérer les données des itinéraires et traiter les
plaintes des utilisateurs.
Principaux cas d’utilisation :
 Pour les passagers :
o Rechercher un itinéraire.
o Soumettre une plainte ou une requête.
o Recevoir des notifications en temps réel.
 Pour les administrateurs :
o Ajouter, modifier, ou supprimer des itinéraires.
o Traiter les plaintes ou requêtes des passagers.

(Remarque : un exemple visuel est fourni ici ; si besoin, je peux générer

un fichier basé sur vos descriptions.)

b. Diagramme de classes
Le diagramme de classes montre les entités principales du système et leurs
relations.
Classes principales :
1. Utilisateur (parent de Passager et Administrateur) :
o Attributs : id, nom, email, motDePasse.
o Méthodes : seConnecter(), seDeconnecter().
2. Bus :
o Attributs : numeroBus, itineraire, tarif.
o Méthodes : obtenirDetailsBus().
3. Requete :
 o Attributs : idRequete, description, statut.
o Méthodes : soumettreRequete(), consulterStatut().
4. Reclamation (hérite de Requete) :
o Attributs supplémentaires : contenu, reponse.
o Méthodes : traiterReclamation().
Diagramme simplifié :
Utilisateur
|-- Passager
|-- Administrateur
Bus
Requete
|-- Reclamation

c. Diagramme de séquence
Ce diagramme illustre l’interaction entre les composants pour une recherche
d’itinéraire.
Scénario : Le passager recherche un itinéraire via l’application.
1. Le passager saisit son point de départ et sa destination.
2. L’application mobile envoie une requête au serveur via une API.
3. Le serveur interroge la base de données MySQL.
4. Les résultats (numéros de bus, horaires, tarifs) sont renvoyés à
l’application.
5. L’application affiche les résultats au passager.
Exemple visuel :
Passager -> Application : Entrer départ et destination
Application -> Serveur : Requête API
Serveur -> Base de données : Rechercher itinéraires
Base de données -> Serveur : Résultats
Serveur -> Application : Transmettre résultats
Application -> Passager : Afficher itinéraires

4.2. Architecture technique

Le système City Bus utilise une architecture en couches pour séparer les
responsabilités, améliorer la maintenance et permettre l’évolution du projet.
a. Description des couches
1. Couche présentation (Frontend) :
o Inclut l’application Android pour les passagers et le portail web
pour les administrateurs.
o Gère l’interaction utilisateur et l’affichage des données.
2. Couche logique métier (Backend) :
o Développée en PHP, elle gère les règles métier, comme la
validation des requêtes ou le calcul des itinéraires.
3. Couche données (Base de données) :
o Stocke les informations sur les utilisateurs, itinéraires, requêtes,
et plaintes.
o Base de données MySQL structurée pour des accès rapides.
b. Schéma de l’architecture
+----------------------+ +--------------------+
| Application Android | ---> | Serveur PHP |
+----------------------+ +--------------------+
| |
| REST API (GET/POST) |
v v
+----------------------+ +--------------------+
| Portail Administratif | ---> | Base de données |
+----------------------+ +--------------------+
c. Flux de données
1. Les utilisateurs saisissent leurs requêtes (par exemple : recherche
d’itinéraire).
 2. Le frontend envoie les données au backend via des API REST.
3. Le backend interagit avec la base de données pour récupérer ou
modifier les informations.
4. Les résultats sont renvoyés au frontend pour être affichés.

4.3. Exemples concrets de code

a. Connexion sécurisée
Objectif : Authentifier un utilisateur avec cryptage du mot de passe.
Code PHP (Backend) :
<?php
function seConnecter($email, $motDePasse) {
$connexion = new mysqli('localhost', 'root', '', 'citybus_db');
$requete = $connexion->prepare("SELECT motDePasse FROM Utilisateurs
WHERE email = ?");
$requete->bind_param('s', $email);
$requete->execute();
$resultat = $requete->get_result();

if ($resultat->num_rows > 0) {
$ligne = $resultat->fetch_assoc();
if (password_verify($motDePasse, $ligne['motDePasse'])) {
echo "Connexion réussie !";
} else {
echo "Mot de passe incorrect.";
}
} else {
echo "Utilisateur introuvable.";
}
$connexion->close();
}
?>
b. Recherche d’itinéraires
Objectif : Trouver les bus disponibles entre un point de départ et une
destination.
Code SQL (Requête vers MySQL) :
SELECT numeroBus, tarif
FROM Bus
WHERE itineraire LIKE '%pointDepart%' AND itineraire LIKE '%destination%';
Code PHP (Backend) :
<?php
function rechercherItineraires($depart, $destination) {
$connexion = new mysqli('localhost', 'root', '', 'citybus_db');
$requete = $connexion->prepare("SELECT numeroBus, tarif FROM Bus
WHERE itineraire LIKE ? AND itineraire LIKE ?");
$depart = "%" . $depart . "%";
$destination = "%" . $destination . "%";
$requete->bind_param('ss', $depart, $destination);
$requete->execute();
$resultats = $requete->get_result();

while ($ligne = $resultats->fetch_assoc()) {

echo "Bus : " . $ligne['numeroBus'] . " - Tarif : " . $ligne['tarif'] . "
€<br>";
}
$connexion->close();
}
?>
c. Gestion des plaintes
Objectif : Enregistrer une plainte dans la base de données.
Code PHP (Backend) :
<?php
function soumettrePlainte($utilisateurId, $description) {
$connexion = new mysqli('localhost', 'root', '', 'citybus_db');
$requete = $connexion->prepare("INSERT INTO Reclamations
(idUtilisateur, contenu, statut) VALUES (?, ?, 'En cours')");
$requete->bind_param('is', $utilisateurId, $description);
$requete->execute();
echo "Plainte soumise avec succès !";
$connexion->close();
}
?>

Conclusion
Les diagrammes UML, l’architecture technique en couches et les exemples de
code proposés illustrent la solidité et la faisabilité technique du projet City
Bus. Ces éléments permettent d’assurer une expérience utilisateur fluide et
une gestion efficace pour les administrateurs. Si besoin, des sections
supplémentaires peuvent être développées pour approfondir chaque
composant.

6. Diagrammes

 Diagramme de flux de données (DFD) :

o Illustre les interactions entre les utilisateurs, l'application mobile,
le portail web et la base de données.
 o

 Complexité Cyclomatique :
o Calculée à 8 chemins indépendants pour garantir une couverture
complète des tests.
o
7. Exigences Non Fonctionnelles

 Performance :
o Les requêtes serveur doivent répondre en moins de 2 secondes.
o Calcul des tarifs optimisé pour un temps d'exécution inférieur à
une seconde.
 Sécurité :
o Cryptage des mots de passe et des données sensibles.
o Déconnexion automatique après une période d'inactivité.
4. Ajout des métriques de performance
La section suivante définit en détail les métriques de performance pour le
projet City Bus, notamment la performance prévue et les indicateurs de
succès. Ces mesures permettront de surveiller la qualité du système,
d’évaluer son efficacité et de valider son succès après le déploiement.

4.1. Performance prévue

Les objectifs de performance garantissent que l'application et le portail web
répondent rapidement aux requêtes des utilisateurs, même avec un grand
nombre d'utilisateurs simultanés.
a. Temps de réponse attendu
Le temps de réponse des requêtes est un indicateur clé pour l’expérience
utilisateur. Le projet vise un temps de réponse maximal inférieur à 2
secondes pour la plupart des opérations clés, comme la recherche
d'itinéraire ou la soumission de plaintes.
Analyse par fonctionnalité :
1. Recherche d'itinéraires :
o Objectif : Temps de réponse < 2 secondes.
o Méthodes utilisées pour atteindre cet objectif :
 Optimisation des requêtes SQL avec indexation de la base
de données.
 Utilisation de la mise en cache pour stocker
temporairement les itinéraires les plus fréquemment
consultés.
2. Connexion sécurisée :
 o Objectif : Temps de réponse < 1 seconde après soumission des
identifiants.
o Méthodes utilisées :
 Utilisation d'API rapides avec une logique optimisée.
 Utilisation de protocoles sécurisés (HTTPS) avec une faible
surcharge.
3. Soumission de plaintes :
o Objectif : Temps de réponse < 1,5 seconde.
o Méthodes utilisées :
 Optimisation des appels API avec validation minimale côté
serveur.

b. Charge utilisateur prévue

Une évaluation de la charge utilisateur permet d'anticiper le nombre
d’utilisateurs simultanés que le serveur doit être capable de supporter.
Scénarios d'utilisation :
1. Utilisateurs simultanés lors des heures de pointe :
o Estimation : jusqu'à 1 000 utilisateurs simultanés en période
de forte affluence.
o Exemple : Lors des heures de début et de fin de travail dans les
zones urbaines avec un fort recours aux transports en commun.
2. Capacité du serveur :
o Le serveur devra gérer des requêtes simultanées tout en
maintenant un temps de réponse optimal.
Technologies pour supporter la charge prévue :
1. Utilisation de serveurs hébergés sur le cloud évolutif (ex : AWS,
Google Cloud).
2. Répartition de la charge avec un serveur en load balancing pour
équilibrer le nombre de connexions actives.
3. Optimisation des bases de données avec l'indexation, des requêtes
paramétrées, et une architecture NoSQL si nécessaire pour gérer les
données en temps réel.
Résumé de la performance prévue
Stratégie pour atteindre
Objectif Mesure
l'objectif

Temps de réponse pour Optimisation SQL, mise en

< 2 secondes
la recherche d'itinéraire cache des réponses fréquentes

Temps de réponse pour Optimisation des API avec

< 1 seconde
la connexion sécurisée protocole HTTPS

Temps de réponse pour

Validation rapide côté serveur
la soumission de < 1,5 seconde
avec logique légère
plaintes

Jusqu'à 1 000 Utilisation de serveurs cloud

Charge utilisateur
connexions évolutifs avec équilibrage de
prévue simultanée
simultanées charge

4.2. Indicateurs de succès

Les indicateurs de succès mesurent si le projet atteint ses objectifs
principaux après le déploiement. Ils permettent d’évaluer l’impact du
système sur l’expérience utilisateur et l’efficacité des opérations.
a. Taux d’adoption par les utilisateurs
Cet indicateur mesure le pourcentage d'utilisateurs qui utilisent activement
l'application ou le portail après son déploiement.
Objectifs :
 Objectif initial : 30 % d'utilisateurs actifs après 6 mois de
déploiement.
 Objectif moyen après 1 an : 50 % des utilisateurs cibles adoptent
l’application comme principale source d’information pour leurs trajets.
Stratégies pour atteindre cet objectif :
1. Campagnes de sensibilisation :
o Utiliser les médias sociaux et les campagnes publicitaires dans
les zones de forte utilisation des transports en commun.
2. Faciliter l’accès avec une interface intuitive :
 o Un design simple et adapté aux besoins variés des utilisateurs
finaux.
3. Implémentation de fonctionnalités attractives :
o Notifications en temps réel, historique de recherche, et gestion
personnalisée des trajets.

b. Réduction des temps de recherche d’itinéraires

Cet indicateur mesure la rapidité avec laquelle les utilisateurs trouvent leurs
trajets via l’application, comparé aux méthodes traditionnelles.
Objectifs :
1. Réduire le temps moyen de recherche de 40 % par rapport aux
méthodes manuelles.
o Exemple : Passer de 8 minutes à environ 3 minutes grâce aux
fonctionnalités intuitives et rapides.
Stratégies pour atteindre cet objectif :
1. Optimiser l’algorithme de recherche :
o Requêtes rapides avec indexation avancée dans la base de
données.
2. Améliorer l’interface utilisateur :
o Proposer des options avec une saisie automatique et un affichage
clair des itinéraires disponibles.
3. Intégrer des fonctionnalités de prédiction et de suggestions :
o Proposer des trajets souvent empruntés selon la localisation et
l'historique de l'utilisateur.

Résumé des indicateurs de succès

Indicateur de
Objectif Mesures attendues
succès

Taux d’adoption par 30 % après 6 mois, Suivi du nombre d'installations et

les utilisateurs 50 % après 1 an d'utilisations actives
Indicateur de
Objectif Mesures attendues
succès

Temps de recherche Comparaison entre le temps moyen

Réduction de 40 %
d'itinéraires avant et après le déploiement

Conclusion
Les métriques de performance permettent de valider que le projet City Bus
reste efficace, rapide, et adapté aux besoins de ses utilisateurs. En
surveillant régulièrement ces indicateurs après le déploiement, l’équipe de
développement pourra ajuster ses priorités pour garantir la qualité et
l’adoption du produit.
conc

8. Estimations et Planification

 Taille du projet : 153 points de fonction (FP).

 Efforts estimés : 4,53 mois-personnes.
 Calendrier :
o Analyse des besoins : 2 semaines.
o Conception : 3 semaines.
o Développement : 4 semaines.
o Tests et déploiement : 2 semaines.
3. Ajout d'une section sur la gestion du projet
La gestion efficace du projet City Bus repose sur une méthodologie adaptée,
une planification rigoureuse et une bonne répartition des tâches entre les
différentes étapes. Cette section introduit la méthodologie utilisée ainsi que
la planification avec les outils Diagramme Gantt et Diagramme PERT pour
une gestion optimale.

3.1. Méthodologie Agile

La méthodologie Agile est utilisée pour assurer une gestion progressive,
itérative et collaborative du projet City Bus. Cette approche permet de
diviser le projet en phases itératives (sprints), favorise l'adaptabilité aux
changements et améliore la collaboration avec les parties prenantes.
Principe de la méthodologie Agile :
L'approche Agile repose sur des cycles de développement courts appelés
sprints, chacun avec des objectifs précis et une revue d’étape pour évaluer
les progrès.

Étapes clés de la méthodologie :

1. Analyse des besoins :
o Objectif : Recueillir les exigences des utilisateurs finaux
(passagers, administrateurs) ainsi que les attentes des parties
prenantes.
o Résultat attendu : Backlog complet avec toutes les
fonctionnalités prioritaires.
2. Planification et conception :
o Objectif : Définir les priorités, les tâches nécessaires, et préparer
l'architecture.
o Résultat attendu : Conception de l'architecture, planification des
sprints et préparation des outils.
3. Développement en sprints :
o Objectif : Développer les fonctionnalités par itérations de 2
semaines (par exemple). Chaque sprint produit une partie
fonctionnelle du produit.
o Résultat attendu : Livraison incrémentielle des fonctionnalités.
4. Revue de sprint :
o Objectif : Évaluer les fonctionnalités développées à la fin de
chaque itération avec les parties prenantes pour s'assurer que
leurs besoins sont bien compris.
o Résultat attendu : Ajustement du backlog si nécessaire.
5. Tests continus :
o Objectif : Identifier et corriger les bugs. Assurer la qualité du
produit avec des tests fonctionnels et unitaires.
o Résultat attendu : Application sans bugs majeurs.
6. Déploiement et mise en production :
 o Objectif : Mettre l'application et le portail web en ligne après
validation finale.
o Résultat attendu : Mise en place de l'infrastructure pour
permettre l’accès aux utilisateurs finaux.

Exemple : Cycle d'un Sprint

Un sprint pourrait suivre le modèle suivant sur une période de 2 semaines :
Jour Activité

Lundi Réunion de planification pour le sprint.

Développement des fonctionnalités prévues dans le

Mardi - Jeudi
backlog.

Tests internes pour valider les fonctionnalités

Vendredi
développées.

Fin de la Revue avec les parties prenantes pour valider les

semaine résultats.

3.2. Diagramme Gantt

Le Diagramme Gantt est un outil visuel qui permet de planifier les
différentes étapes du projet, leurs durées et leurs interdépendances.
Planification avec le Gantt :
Durée (en
Phase Dates prévues
semaines)

01/11/2024 -
Analyse des besoins 2
14/11/2024

15/11/2024 -
Conception & planification 3
28/11/2024

29/11/2024 -
Développement (sprints) 6
10/01/2025

11/01/2025 -
Tests 2
24/01/2025

Déploiement et mise en 1 25/01/2025 -

 Durée (en
Phase Dates prévues
semaines)

production 31/01/2025
Représentation visuelle du Gantt :
Utilisez un outil comme Microsoft Project ou un tableau Gantt généré avec
Google Sheets pour représenter ces durées.

3.3. Diagramme PERT

Le Diagramme PERT est une autre méthode utilisée pour visualiser la
séquence des tâches, leurs interdépendances, et leurs durées estimées dans
le projet. Ce diagramme est essentiel pour anticiper les retards potentiels.
Analyse des tâches dans le PERT :
Durée Durée Durée
Tâche Optimiste Probable pessimiste
(jours) (jours) (jours)

Analyse des besoins 5 10 14

Conception &
7 12 18
planification

Développement des
10 15 22
fonctionnalités

Tests 8 14 18

Déploiement final 3 5 7
Calcul de la durée attendue avec la formule PERT :
La formule utilisée est :
Dureˊeattendue=Optimiste+4(Probable)+Pessimiste6Durée_{attendue} = \
frac{Optimiste + 4(Probable) + Pessimiste}{6}
Par exemple :
Pour la tâche "Développement des fonctionnalités" :
Dureˊe=10+4(15)+226=10+60+226=926≈15,33 jours\text{Durée} = \
frac{10 + 4(15) + 22}{6} = \frac{10 + 60 + 22}{6} = \frac{92}{6} \
approx 15,33 \text{ jours}
Illustration visuelle pour le Diagramme PERT
Les tâches seront interconnectées avec leurs prédécesseurs pour permettre
une meilleure vue d'ensemble. Par exemple :
1. Analyse des besoins doit être terminée avant de passer à la
conception et planification.
2. La phase développement commence après que la planification est
validée.
3. Les tests démarrent après la phase de développement.

Conclusion :
Les outils méthodologiques utilisés ici, notamment la méthodologie Agile,
le diagramme Gantt, et le diagramme PERT, permettent d'assurer que
chaque phase est bien planifiée, surveillée, et exécutée dans les délais
impartis.
L'adoption de ces pratiques garantit que le projet City Bus est bien
structuré, qu'il anticipe les retards potentiels, et qu'il reste adaptable aux
besoins des utilisateurs et des parties prenantes.

9. Conclusion

Le projet est conçu pour améliorer la gestion des transports publics et

l'expérience des utilisateurs. Des évolutions futures pourraient inclure :

 Suivi en temps réel des bus.

 Génération et gestion des abonnements.

Si tu veux une autre section plus détaillée ou adaptée, précise la partie à

développer !

Consultant

Dans la phase du cahier des charges, un consultant joue un rôle clé pour
s'assurer que les besoins et les objectifs du projet sont bien définis, alignés
avec les attentes des parties prenantes, et techniquement faisables. Voici les
principales responsabilités et contributions d'un consultant à cette étape :

1. Identification des Besoins

Le consultant aide à :

 Comprendre les attentes des parties prenantes (clients, utilisateurs

finaux, équipes techniques).
 Analyser les processus existants pour identifier les lacunes ou
inefficacités.
 Traduire les besoins métiers en exigences fonctionnelles claires et
compréhensibles.

2. Définition des Objectifs

 Assister dans la formulation des objectifs du projet pour qu'ils

soient précis, mesurables et réalistes.
 Prioriser les fonctionnalités en fonction des besoins critiques et des
contraintes du projet (temps, budget, etc.).

3. Analyse des Contraintes

 Identifier les contraintes techniques, organisationnelles ou

réglementaires qui pourraient influencer le projet.
 Proposer des alternatives pour gérer ou contourner ces contraintes.

4. Validation Technique

 Vérifier la faisabilité technique des exigences listées dans le cahier des

charges.
 Conseiller sur les technologies, outils, et méthodologies les mieux
adaptés au projet.
5. Coordination et Communication

 Jouer le rôle d’intermédiaire entre les parties prenantes non techniques

(clients) et les équipes techniques.
 S'assurer que tout le monde a une compréhension partagée du
projet.

6. Prévention des Risques

 Identifier les risques potentiels liés à la portée, à la conception ou à

l'implémentation du projet.
 Recommander des plans d'atténuation pour réduire l'impact des
risques identifiés.

7. Validation du Cahier des Charges

 Relire et valider le document final pour s'assurer qu'il :

o Est complet et clair.
o Décrit précisément les livrables attendus.
o Contient toutes les exigences fonctionnelles et non fonctionnelles
nécessaires.
o Respecte les standards de qualité attendus.

Un consultant agit donc comme un expert et un guide pour orienter le

projet dans la bonne direction dès le départ, évitant ainsi des erreurs
coûteuses ou des incompréhensions.

Diagramm de gantt
 Tâche Début Fin Durée (jours)
Analyse des besoins 01/11/2024 14/11/2024 14
Conception 15/11/2024 28/11/2024 14
Développement 29/11/2024 20/12/2024 22
Tests 21/12/2024 05/01/2025 15
Déploiement 06/01/2025 10/01/2025 5

2. Tableau pour le Diagramme PERT

Tâche Nom Durée (jours) Prédécesseurs
A Analyse des besoins 14 -
B Conception 14 A
C Développement 21 B
D Tests 15 C
E Déploiement 5 D

City bus 2eme partie

ANALYSE DES BESOINS

Besoins fonctionnels

1. Enregistrement et connexion des utilisateurs :

a. Les utilisateurs doivent pouvoir créer un compte, fournir un nom
d'utilisateur, un mot de passe et des informations de contact.
b. Les administrateurs et les utilisateurs doivent se connecter pour
accéder aux fonctionnalités spécifiques.
2. Recherche d'itinéraires de bus :
a. Les utilisateurs doivent entrer leur point de départ et leur
destination pour obtenir des informations sur les itinéraires, y
compris le numéro de bus et le tarif.
3. Gestion des informations des bus :
a. Les administrateurs doivent pouvoir ajouter, modifier ou
supprimer des informations sur les itinéraires de bus via un
portail web.
4. Gestion des requêtes et plaintes :
a. Les utilisateurs peuvent soumettre des demandes ou des plaintes
via l'application mobile.
b. Les administrateurs gèrent ces requêtes via le portail web.
5. Notifications :
a. L'application doit notifier les utilisateurs des mises à jour ou des
changements dans les itinéraires.

Besoins non fonctionnels

1. Performance :
a. Les requêtes serveur doivent être rapides, avec un délai minimal
pour afficher les résultats.
b. L'algorithme de calcul des tarifs doit être optimisé pour fournir
des réponses instantanées.
2. Compatibilité :
a. L'application mobile doit être compatible avec les appareils
Android version 5.0 et plus.
3. Sécurité :
a. Les mots de passe des utilisateurs ne doivent pas être affichés en
clair ni stockés sans cryptage.
 b. Les sessions doivent expirer après une période d'inactivité pour
garantir la sécurité.
4. Fiabilité :
a. Le serveur doit avoir un taux de disponibilité d'au moins 98 %
pour éviter les interruptions.
5. Facilité d'utilisation :
a. L'interface utilisateur doit être intuitive et conviviale, adaptée à
des utilisateurs non techniques.
6. Portabilité :
a. L'application mobile doit pouvoir être utilisée sur différents
appareils Android sans configuration complexe.
7. Documentation :
a. Une documentation en ligne ainsi qu’un tutoriel vidéo doivent
être fournis pour aider les utilisateurs.

Ces exigences couvrent les aspects nécessaires pour le développement et

l'exploitation efficace du système.

Étude de faisabilité

1. Technique :
a. Plateformes prises en charge : Android (version 5.0 et plus),
serveurs web basés sur Linux avec base de données MySQL.
b. Technologies utilisées : Android SDK, PHP pour les interactions
serveur, HTTP et TCP/IP comme protocoles principaux.
c. Limites : L'application est conçue pour des mobiles avec 20 Mo
de mémoire disponible.
2. Opérationnelle :
a. Utilisateurs cibles : Passagers de bus pour rechercher des
trajets et des tarifs, administrateurs pour gérer les données.
b. Accessibilité : L'application sera intuitive et nécessite une
connexion Internet.
c. Objectif : Réduire les frictions liées à la recherche de trajets et à
la gestion des données de transport.
3. Économique :
a. Coût estimé : 4.53 mois-personne (PM).
 b. Points fonctionnels estimés : 153 FP, ce qui indique un projet
de taille modérée.
3. Étude de Faisabilité Approfondie
L’étude de faisabilité permet de vérifier que le projet City Bus est viable
techniquement, économiquement, et opérationnellement. Cette section
explore en détail ces dimensions, tout en intégrant une évaluation
comparative des solutions existantes et une analyse des limites techniques.

3.1. Faisabilité technique

Technologies utilisées dans le projet :
1. Frontend :
o Android Studio pour le développement de l’application mobile.
o XML pour la conception de l’interface utilisateur intuitive et
légère.
2. Backend :
o PHP pour les interactions serveur et la logique métier.
o MySQL pour le stockage des données des utilisateurs, itinéraires,
et requêtes.
3. Communication :
o API RESTful utilisant HTTP avec les méthodes GET, POST, PUT,
DELETE pour une interaction rapide entre le mobile et le serveur.
o Retrofit pour gérer les requêtes côté Android.
Avantages techniques :
 Compatibilité : Compatible avec Android 5.0+, couvrant une majorité
d’appareils mobiles.
 Efficacité : Architecture en couches séparant la logique métier,
l’interface utilisateur et la base de données pour faciliter la
maintenance.
 Sécurité : Cryptage des mots de passe et transmission des données
via HTTPS pour éviter les attaques.
Limites techniques :
 Taille de l’application limitée à 20 Mo :
 o Cette contrainte exige un code optimisé et une gestion efficace
des ressources pour éviter les surcharges.
o Solution : Utilisation de bibliothèques légères et minimisation
des fichiers multimédias intégrés dans l'application.
 Temps de réponse des requêtes (<2 secondes) :
o Une faible latence est cruciale pour une expérience utilisateur
fluide.
o Solution : Indexation des tables dans MySQL et optimisation des
requêtes SQL pour un accès rapide aux données.
 Dépendance à la connectivité Internet :
o Les fonctionnalités nécessitent une connexion stable, ce qui peut
limiter l’utilisation dans des zones mal desservies.
o Solution : Implémentation d’une mise en cache locale pour des
informations essentielles (itinéraires fréquents).

3.2. Faisabilité opérationnelle

Points de force :
1. Interface intuitive : Accessible aux utilisateurs ayant peu de
compétences techniques.
2. Centralisation des données : Simplifie la gestion des informations
pour les administrateurs.
3. Notifications en temps réel : Renforce la communication avec les
usagers en cas de perturbations.
Défis opérationnels :
1. Formation des administrateurs :
o Les administrateurs doivent être formés pour gérer efficacement
les fonctionnalités du portail web.
o Solution : Prévoir des tutoriels vidéo et une documentation
détaillée pour simplifier la prise en main.
2. Gestion des retours utilisateurs :
o Un volume élevé de requêtes ou de plaintes peut submerger les
administrateurs.
 o Solution : Implémenter un système de priorisation automatique
des plaintes (par exemple, urgentes, non urgentes).

3.3. Faisabilité économique

Analyse coûts-bénéfices :
1. Coûts estimés :
o Temps de développement : 4,53 mois-personnes.
o Budget technique : Hébergement, licences logicielles, et
maintenance régulière.
2. Bénéfices attendus :
o Réduction des coûts opérationnels grâce à l’automatisation.
o Amélioration de la satisfaction des passagers, augmentant
potentiellement leur fidélité au système de transport public.
o Possibilité de monétisation future (publicités ou abonnements
pour fonctionnalités avancées).

3.4. Évaluation comparative des solutions existantes

Critères d’analyse :
 Fonctionnalités proposées.
 Accessibilité pour les utilisateurs finaux.
 Facilité de gestion pour les administrateurs.
City Bus (projet
Solution Citymapper Moovit
actuel)

Grandes villes Grandes villes Adapté aux besoins

Couverture
uniquement uniquement locaux

Recherche Avancée, mais Avancée, mais pas Personnalisée selon

d'itinéraires générique personnalisée les besoins locaux

Présentes, mais Notifications en

Notifications Présentes
peu réactives temps réel
 City Bus (projet
Solution Citymapper Moovit
actuel)

Gestion Tableau de bord

Non incluse Non incluse
administrative intégré
Conclusion de l’analyse comparative :
Les solutions existantes comme Citymapper ou Moovit offrent des
fonctionnalités puissantes, mais elles ne sont pas adaptées aux besoins
spécifiques des petites ou moyennes villes. Le projet City Bus se distingue
par sa personnalisation et son focus sur les utilisateurs et administrateurs
locaux.

3.5. Résolution des limites techniques

Pour surmonter les limites identifiées :
Limite Solution proposée

Taille limitée Optimisation du code, utilisation de bibliothèques légères,

(<20 Mo) mise en cache locale pour réduire les appels.

Dépendance à Ajout de fonctionnalités hors ligne pour les itinéraires

Internet fréquents.

Volume élevé de
Système de priorisation basé sur l’urgence et l’importance.
plaintes

Latence des Optimisation des requêtes SQL, indexation des bases de

requêtes données.

Résumé de l’étude de faisabilité

Le projet City Bus est techniquement réalisable grâce à une architecture
bien conçue et des solutions éprouvées. Il est opérationnellement et
économiquement viable, répondant aux besoins des passagers et des
administrateurs avec une personnalisation qui le différencie des solutions
existantes.
Rôle du consultant

 Analyse initiale :
o Identifier les exigences spécifiques des utilisateurs (passagers et
administrateurs).
o S'assurer que les contraintes techniques, comme la capacité du
serveur et la compatibilité API, sont respectées.
 Conception :
o Valider le design des interfaces utilisateur (pages de connexion,
recherche, gestion).
o Proposer des fonctionnalités futures, comme le suivi en temps
réel des bus ou la génération de passes.
 Suivi et optimisation :
o Aider dans la mise en œuvre des tests fonctionnels (boîte noire)
et structurels (boîte blanche).
o Gérer les risques identifiés : perte de données, délais serrés,
cohésion de l'équipe.

Diagramme de sequense
CONCEPTION

1. Concepteur

Le concepteur est responsable de planifier, structurer et superviser le

développement du système. Voici un résumé des responsabilités :

 Analyse des exigences : Traduire les besoins des utilisateurs en

spécifications techniques.
 Modélisation UML : Concevoir les diagrammes nécessaires (classes,
objets, séquences, etc.).
 Documentation : Assurer la clarté des conceptions pour l'équipe de
développement.
Diagramme de classe
Diagramme d’objet
Développement : Techniques et Technologies

Techniques Utilisées

1. Développement Orienté Objet (OOP)

a. Modélisation avec des classes pour Utilisateur, Bus, Requete,
et Reclamation.
b. Réutilisation et modularité du code.
2. Architecture en Couches
a. Frontend (Couche présentation) : Interface utilisateur.
b. Backend (Couche logique métier) : Traitement des données
et règles métier.
c. Base de données (Couche données) : Stockage des
informations.
3. API RESTful
a. Communication entre l’application Android et le serveur via HTTP.
b. Méthodes : GET, POST, PUT, DELETE.
4. Approche Agile
a. Découpage du développement en sprints pour une meilleure
organisation.

Langages et Technologies

1. Frontend :
a. XML : Conception de l’interface utilisateur.
b. Android Studio : IDE principal pour le développement mobile.
2. Backend :
a. PHP : Développement des API backend.
b. MySQL : Base de données pour stocker les utilisateurs,
itinéraires, requêtes, et réclamations.
3. Communication :
a. Retrofit : Bibliothèque pour interagir avec les API REST.

Structure de la Base de Données

 Table Utilisateur : Stocke les informations des utilisateurs.

o Attributs : idUtilisateur, nom, email, motDePasse.
 Table Bus : Contient les itinéraires et tarifs.
 o Attributs : numeroBus, itineraire, tarif.
 Table Requete : Enregistre les demandes des utilisateurs.
o Attributs : idRequete, description, date.
 Table Reclamation : Gère les réclamations.
o Attributs : idReclamation, contenu, statut.

Fonctionnalités Clés

1. Inscription et Connexion :
a. Formulaire pour créer ou accéder à un compte utilisateur.
b. Hachage des mots de passe avec bcrypt.
2. Recherche d’Itinéraires :
a. Entrée : Point de départ et destination.
b. Résultat : Numéro de bus et tarif affichés à l’utilisateur.
3. Soumission de Réclamations :
a. Formulaire pour envoyer une réclamation.
b. Stockage des réclamations dans la base de données.

Exemples de Code

1. Insertion d’un utilisateur (PHP) :

$query = "INSERT INTO Utilisateur (email, motDePasse) VALUES

('$email', '$hashedPassword')";
mysqli_query($conn, $query);

2. Requête SQL pour les itinéraires :

SELECT numeroBus, tarif FROM Bus WHERE itineraire LIKE

'%pointDepart%' AND itineraire LIKE '%destination%';

3. Structure XML pour l’écran de recherche :

<Spinner android:id="@+id/source" ... />

<Spinner android:id="@+id/destination" ... />
<Button android:id="@+id/findRoute" ... />

Sécurité

 Authentification via tokens (JWT).

 Hachage des mots de passe.
 Requêtes SQL paramétrées pour éviter les injections.

5. Propositions d'Améliorations Futures

Pour renforcer l’efficacité, l’utilité, et la durabilité du projet City Bus,
plusieurs axes d'amélioration ont été identifiés. Ces propositions concernent
à la fois l’ajout de nouvelles fonctionnalités pour améliorer l’expérience
utilisateur et l’amélioration de l’architecture technique pour soutenir la
croissance du nombre d’utilisateurs.

5.1. Fonctionnalités évolutives

Les fonctionnalités évolutives visent à répondre aux besoins des utilisateurs,
tout en anticipant les tendances technologiques et les attentes des
utilisateurs finaux.
a. Suivi en temps réel des bus (avec GPS)
Objectif :
Fournir aux utilisateurs des informations précises sur la localisation actuelle
des bus et permettre une meilleure planification de leurs trajets.
Fonctionnement :
 Utilisation de la technologie GPS en temps réel pour suivre la
position des bus.
 Afficher sur l’interface utilisateur la position en temps réel des bus sur
une carte interactive.
Exemples d'utilisations :
 1. Alertes de proximité :
o Notifier l'utilisateur lorsqu’un bus s’approche de son point d’arrêt.
2. Planification optimisée :
o Afficher l’horaire réel et les délais estimés grâce aux données
GPS.
Technologies nécessaires :
 Intégration de services GPS avec des technologies comme Google
Maps API, Mapbox, ou des services GPS tiers.
 Intégration en temps réel avec le serveur via API RESTful.

b. Intégration avec des systèmes de paiement en ligne

Objectif :
Permettre aux passagers de payer leurs trajets directement via l’application
ou le portail web.
Fonctionnement :
 Intégration avec des services de paiement en ligne comme Stripe,
PayPal, ou des systèmes nationaux de paiement.
 Possibilité de créer un historique de paiements avec options de
remboursements en cas d'annulations ou de changements.
Avantages pour l'utilisateur :
1. Réduction des temps d'attente pour l'achat de tickets.
2. Meilleure sécurité avec des paiements numériques sécurisés.
Exemple :
 Une fois l'itinéraire sélectionné, l'utilisateur peut sélectionner l'option
"Acheter un ticket" pour finaliser le paiement.

c. Génération et gestion des abonnements

Objectif :
Proposer des plans d'abonnement aux usagers réguliers afin de faciliter
l’accès aux transports en commun avec un coût fixe sur une période donnée.
Fonctionnement :
 Création de formules d’abonnement flexibles (ex. : mensuel, annuel,
par zones).
 Gestion automatisée de l'activation, renouvellement, et annulation des
abonnements.
Avantages :
1. Simplifier l’accès aux transports pour les usagers réguliers.
2. Réduction de la gestion administrative grâce à l’automatisation.
Stratégies techniques :
 Intégration avec le serveur backend pour valider les paiements
récurrents.
 Développement d’une base de données sécurisée pour stocker les
informations d’abonnement.

5.2. Évolutivité technique

L’évolutivité vise à préparer l’infrastructure pour la croissance future du
nombre d'utilisateurs tout en maintenant des performances optimales.
a. Utiliser des bases de données distribuées si le volume
d'utilisateurs augmente
Objectif :
Assurer la haute disponibilité et la rapidité du système en cas de forte
augmentation du nombre d'utilisateurs.
Contexte :
Avec l'augmentation du nombre de requêtes simultanées, une base de
données unique pourrait devenir un goulot d’étranglement.
Stratégie :
Mettre en place une architecture de bases de données distribuées pour
diviser la charge et assurer la continuité de service.

Exemples de solutions :
1. Utilisation de bases NoSQL distribuées :
 o Par exemple, MongoDB Atlas, qui permet la réplication
automatique et une distribution rapide des requêtes.
2. Mise en place de clusters de base de données SQL :
o Utiliser des solutions comme MySQL Cluster ou Amazon
Aurora pour permettre des lectures/écritures simultanées sur
plusieurs nœuds.
Avantages :
 Réduction du temps de réponse même avec un grand nombre de
connexions simultanées.
 Haute disponibilité avec un serveur de secours en cas de panne du
serveur principal.

b. Optimisation avec le Cloud Computing

Pour une meilleure gestion des pics de trafic et de l'évolution progressive de
la charge, l'architecture en cloud computing peut être utilisée :
1. Utiliser AWS, Google Cloud, ou Azure pour l'infrastructure
backend :
o Ces plateformes permettent d'ajuster automatiquement la
capacité du serveur en fonction de la demande avec des
technologies comme le "auto-scaling".
2. Serveurs régionaux géographiquement distribués :
o Déployer des serveurs dans différentes régions pour s'assurer
que chaque utilisateur accède au serveur le plus proche.
3. Utilisation de CDN (réseau de diffusion de contenu) :
o Réduire les délais d'accès aux données statiques avec des
réseaux comme Cloudflare ou Amazon CloudFront.

Résumé des Propositions

Technologies
Propositions Objectifs visés
impliquées

Suivi en temps réel des Informer en temps réel sur GPS + Google Maps
bus avec GPS les positions et retards des API / Mapbox API
 Technologies
Propositions Objectifs visés
impliquées

bus

Stripe, PayPal,
Intégration avec des Faciliter l'achat de tickets
passerelles de
systèmes de paiement directement en ligne
paiement locales

Proposer des plans Backend avec

Génération & gestion
d'abonnement adaptés aux MySQL / API pour
des abonnements
usagers réguliers abonnements

Supporter un grand nombre NoSQL comme

Bases de données
d'utilisateurs simultanés MongoDB, MySQL
distribuées
sans dégradation Cluster

Utiliser le Cloud Répondre à la demande en

AWS, Azure, Google
Computing avec temps réel avec un serveur
Cloud
scalabilité automatique dynamique

Conclusion
Les fonctionnalités évolutives permettront au projet City Bus de rester
innovant, pratique et en phase avec les besoins de ses utilisateurs.
Parallèlement, les améliorations techniques, comme l'implémentation de
bases de données distribuées et le recours au cloud computing, garantiront
des performances constantes même avec une montée en charge importante.
Ces axes stratégiques assurent la durabilité, l’optimisation des coûts, et
l’adaptabilité du projet sur le long terme.