ProjetCovoit

ProjetCovoit est une application web de covoiturage développée en PHP procédural avec une architecture MVC simplifiée. Elle permet aux utilisateurs de rechercher, réserver, créer ou modifier des trajets selon leurs besoins, tout en interagissant via un système d’évaluation et de notifications. Chaque utilisateur peut s’inscrire, se connecter, visualiser son historique, noter ses chauffeurs, ou encore choisir des conducteurs favoris pour les retrouver plus facilement.

Le back-office de l’application, accessible aux administrateurs, offre la possibilité de visualiser les utilisateurs, de bannir des comptes mal notés, et d’administrer la plateforme. La sécurité est gérée via une séparation des ré┤les user/admin, un système de session robuste et un mécanisme d’interdiction d’action pour les utilisateurs bannis. Le projet repose sur une base de données relationnelle solide, optimisée pour gérer les trajets, étapes intermédiaires, utilisateurs, réservations, et interactions sociales. L’ensemble de l’interface utilisateur est conéºu pour offrir une navigation fluide et intuitive.

Conception et mise en place de la base de données relationnelle

La base de données est le socle fondamental du projet ProjetCovoit. Elle a été pensée pour modéliser fidèlement l’univers d’une application de covoiturage : utilisateurs, trajets, réservations, avis et notifications y sont interconnectés de manière cohérente. Chaque utilisateur peut créer ou réserver des trajets, déposer un avis sur un conducteur, et marquer certains comme favoris gróce à la table preferred_drivers. Le système assure l’intégrité des données via des relations bien définies et l’usage de clés étrangères, notamment pour sécuriser les suppressions en cascade (ON DELETE CASCADE). Un système de ré┤le (user, admin) et une gestion de bannissement sont également intégrés pour contré┤ler les droits d’action. Cette base robuste est alimentée automatiquement gróce à un fichier fixtures.php qui génère des utilisateurs, trajets, étapes, réservations et avis réalistes. Enfin, elle est optimisée pour interagir avec toutes les fonctionnalités de l’application (recherche, historique, notation, modération...).

Conception et modélisation de la base

Conception et modélisation de la base

La première étape a consisté à concevoir un modèle relationnel complet, en identifiant les entités clés : users, trips, reservations, reviews, notifications, trip_stops, et preferred_drivers. Chaque relation a été structurée avec des clés primaires, des relations 1-N et N-N via des tables de liaison. Les types ont été choisis de manière cohérente pour respecter les bonnes pratiques (ex : ENUM, TIMESTAMP, BOOLEAN). L’objectif était de permettre une gestion fluide des données utilisateurs et des trajets tout en préparant la base à accueillir des fonctionnalités plus avancées (comme les filtres par chauffeur favori ou la gestion des bannissements).

Le modèle relationnel généré (cf. image jointe) montre clairement les entités, leurs relations et les clés étrangères. Chaque table est lisible, normalisée, et connectée de manière logique pour refléter les processus métier du covoiturage.

Recherche de trajets

Cette fonctionnalité permet à l’utilisateur de rechercher des trajets disponibles selon différents critères : ville de départ, ville d’arrivée, date et nom du chauffeur. Elle offre également un filtre avancé permettant d’afficher uniquement les trajets proposés par les chauffeurs que l’utilisateur a ajoutés à ses favoris. Le système s’adapte dynamiquement à chaque champ rempli gróce à une construction conditionnelle de la requête SQL. Celle-ci est exécutée de faéºon sécurisée via des requêtes préparées. Les résultats sont ensuite affichés dans un tableau listant les informations clés du trajet, dont le chauffeur, la date, l’heure, le prix et le nombre de places disponibles. Cette fonctionnalité permet un filtrage rapide et ciblé, améliorant l’expérience utilisateur pour trouver facilement un covoiturage adapté à ses besoins.

Formulaire de recherche Récupération des champs cé┤té contré┤leur Construction dynamique de la requête SQL Exécution de la requête et récupération Affichage des résultats à l’utilisateur

Formulaire de recherche

L’utilisateur accède à une interface de recherche intuitive oé╣ il peut renseigner plusieurs critères pour filtrer les trajets disponibles : ville de départ, ville d’arrivée, date du trajet, ou nom du chauffeur. Une case à cocher optionnelle permet d’activer un filtre qui restreint les résultats aux chauffeurs favoris, si l’utilisateur est connecté. Tous les champs sont facultatifs : le formulaire s’adapte à la saisie partielle ou complète. Le bouton de soumission envoie la requête en POST vers le contré┤leur de traitement.

Affiche le formulaire HTML complet avec tous les champs de filtre et l’option "chauffeurs favoris".

Récupération des champs cé┤té contré┤leur

Lorsque le formulaire est soumis, les champs sont récupérés depuis $_POST dans le contré┤leur. Chaque valeur est stockée dans une variable PHP ($departure, $arrival, etc.) pour être utilisée dans la construction de la requête. Le filtre onlyPreferred est également détecté ici et converti en booléen. Cette étape permet de préparer les données utilisateurs sans traitement direct encore.

Montre la récupération des champs de formulaire dans SearchTripsController.php.

Construction dynamique de la requête SQL

La requête SQL est construite ligne par ligne, selon les champs remplis. Si une ville de départ ou d’arrivée est spécifiée, une clause LIKE est ajoutée ; si la date est renseignée, un filtre = est appliqué. Si le nom du chauffeur est fourni, un filtre sur son email est également inclus. En cas de filtre "chauffeurs favoris", une clause IN (...) est générée à partir des identifiants des conducteurs préférés de l’utilisateur connecté.

Montre l’assemblage progressif de la requête SQL selon les champs renseignés.

Exécution de la requête et récupération

Une fois la requête préparée, elle est sécurisée via prepare() puis exécutée avec les paramètres utilisateur. Le résultat est ensuite récupéré sous forme de tableau associatif gróce à fetchAll(). Le tableau final $trips contient toutes les informations nécessaires pour afficher les résultats dans la vue. Cette étape termine la logique backend du contré┤leur.

Affiche les lignes exécutant la requête SQL avec prepare, execute et fetchAll.

Affichage des résultats à l’utilisateur

Les résultats sont envoyés à la vue search_trips.php, oé╣ une boucle foreach permet de générer une ligne de tableau pour chaque trajet trouvé. Sont affichées : la ville de départ, d’arrivée, la date, l’heure, le nombre de places, le prix, et l’adresse mail du chauffeur. Un lien vers la page de détails du trajet est également généré automatiquement. L’ensemble est affiché dans un tableau HTML clair et responsive.

Montre la boucle d’affichage HTML des résultats avec les données du trajet et le lien "Détails".

Historique des trajets réservés

Cette fonctionnalité permet à un utilisateur connecté de visualiser l’ensemble de ses trajets réservés dans un tableau complet. Il peut y voir les villes de départ et d’arrivée, la date du trajet, l’heure, le nombre de places réservées et l’adresse mail du chauffeur. L’interface affiche également si ce chauffeur a déjà été noté ou ajouté en favori. Le système repose sur des jointures SQL entre reservations, trips et users pour regrouper les informations essentielles. Un tri est effectué selon l’utilisateur connecté, et les données sont enrichies avec des requêtes supplémentaires pour les favoris et les avis déjà déposés. Cela permet à l’utilisateur de garder un historique clair de ses covoiturages passés, et de faciliter l’évaluation ou la replanification avec un chauffeur apprécié.

Contré┤le de session et récupération des trajets Chargement des favoris et chauffeurs déjà notés Affichage de l’historique dans la vue Indication de notation (badge "Déjà noté")

Contré┤le de session et récupération des trajets

Dès qu’un utilisateur accède à l’historique, une vérification de session est effectuée pour s’assurer qu’il est connecté. Ensuite, le contré┤leur récupère tous les trajets liés à cet utilisateur depuis la table reservations, en les joignant avec trips (détails du trajet) et users (chauffeur). Une requête sécurisée est utilisée pour ne charger que les données nécessaires. Si l’utilisateur est banni, une redirection vers la page de login est automatiquement déclenchée.

Affiche la requête SQL complète de récupération des trajets avec jointure sur trips et users.

Chargement des favoris et chauffeurs déjà notés

Une fois les trajets récupérés, deux requêtes supplémentaires sont exécutées pour déterminer les chauffeurs que l’utilisateur a ajoutés à ses favoris (preferred_drivers) et ceux qu’il a déjà notés (reviews). Ces informations sont essentielles pour afficher correctement les badges "Favori" ou "Déjà noté". Les IDs correspondants sont extraits avec array_column() et stockés dans la session pour être facilement accessibles depuis la vue.

Montre les requêtes de récupération des favoris et des chauffeurs notés, et le stockage en session.

Affichage de l’historique dans la vue

La vue utilise une boucle foreach pour afficher chaque trajet dans un tableau HTML. Les données incluent les villes, les horaires, le nombre de places réservées et l’email du chauffeur. En fonction des données en session, un bouton permet d’ajouter ou retirer un chauffeur des favoris. L’interface est claire et dynamique, avec des boutons personnalisés selon le statut du chauffeur (favori ou non).

Affiche la boucle principale foreach avec l’affichage conditionnel des boutons "Ajouter aux favoris" ou "Retirer".

Indication de notation (badge "Déjà noté")

Dans la même boucle, une vérification permet d’indiquer si un chauffeur a déjà été noté. Si ce n’est pas le cas, un petit formulaire apparaé«t pour ajouter une note sur 5 et un commentaire. Sinon, un badge "Déjà noté" est affiché sous le chauffeur. Cela renforce la transparence et encourage l’interaction utilisateur.

Montre l’affichage conditionnel du formulaire de notation ou du badge "Déjà noté" selon les chauffeurs.