Conception et réalisation d'un site web : Air Polytech

Projet du semestre deux.

Auteur : Jérôme Benoit.

Le présent document a pour objectif de rendre compte du projet de réalisation d'un site web pour une compagnie aérienne fictive du nom de “Air Polytech” au sein de l’école d'ingénieur de Luminy Polytech pour la promotion HUGo.
Nous étudierons en premier lieu les besoins de la compagnie aérienne qui seront traduit en différentes phases de réalisation de l'application web :

• conception d'une application web (maquettage de l'Interface Homme-Machine, cinématique de navigation, etc.);
• conception d'une base de données;
• architecture technique couvrant les besoins fonctionnels identifiés;
• implantation de l'application web;
• tests de l'application web autant sur le plan technique que ergonomique.

La compagnie aérienne fictive “Air Polytech” souhaite avoir un site web permettant :

1. à un client de réserver des places sur un vol et son vol retour, de payer la réservation;
2. à un client de rechercher un vol avec les critères primaires de recherche suivant : ville/aéroport et date de départ, ville/aéroport d'arrivée et date d'arrivée. La recherche pourra avoir un mode avancée permettant de faire une recherche avec les critères secondaires de recherche suivant : numéro de vol, classe, statut du vol (en cours, débarquement, etc.), etc.;
3. à un client de se créer un compte qui sera associé à un espace client couvrant la modification de ses informations personnelles et mot de passe, la visualisation, modification ou annulation de ses réservations en cours et la possibilité de s'identifier ou se déconnecter sur le site;
4. à un administrateur de visualiser des statistiques concernant le taux d'occupation des vols, le nombre de vol par maillage depart/arrivée, etc.
5. à un administrateur de gérer (ajout/modification/suppression) les vols, les avions, les pilotes, etc. (le contenu de la base de données).

Il est à noter que certains besoins ont des dépendances : le besoin concernant la réservation est dépendant de la possibilité de se créer un compte (2 dépend de 3).

Le cahier de conception comprend la structure du site, la conception de l'IHM, des cinématiques de navigation, de la base de données et de l'architecture de l'application web.

L'application web comprend deux parties :

• une partie front office pour les clients de la compagnie aérienne;
• une partie back office pour les administrateurs du site permettant de modifier le contenu de la base de données.

La partie front office couvre les fonctionnalités suivantes :

• recherche basique et avancée d'un vol;
• réserver (et payer) un vol aller ou aller/retour;
• visualiser ses réservations;
• modifier une réservation;
• supprimer une réservation sous conditions de date;
• inscription d'un client;
• se connecter;
• se déconnecter;
• modifier les informations personnelles;
• modifier le mot de passe.

La partie front office comprend les pages :

• une page d'accueil;
• une page de recherche;
• une page de paiement d'une réservation;
• une page d'inscription;
• une page de connexion;
• une page pour espace client;
• une page de modifications des informations personnelles;
• une page de modifications du mot de passe;
• une page pour les réservations en cours;
• une page pour modifier une réservation.

Les pages de la partie front office sont découpées en 3 parties :

• L'entête qui comprend le nom/logo de la compagnie, un menu contextuel de navigation (Accueil | Recherche - | Réservations -), les informations sur la connexion et l'espace client;
• Le corps de la page qui contient les informations liées au contexte de navigation;
• Le pieds qui comprend les éventuel(le)s informations légales et liens externes.

La partie back office couvre les fonctionnalités suivantes :

• connexion;
• visualisation des diverses statistiques;
• visualiser, modifier, supprimer des données en base.

La partie back office comprend les pages :

• une page de connexion;
• une page de visualisation des diverses statistiques;
• une page pour choisir le type de données à gérer;
• une page pour visualiser un type de données : vols, classes, pilotes, etc.

Les pages de la partie back office sont découpées en 3 parties :

• L'entête qui comprend le nom/logo de la compagnie, un menu contextuel de navigation (Statistiques | Administration), les informations sur la connexion et l'espace administrateur;
• Le corps de la page qui contient les informations liées au contexte de navigation;
• Le pieds qui comprend les éventuels liens externes.

Une maquette papier implantant la structure ci-dessus a été réalisée pour la partie front office seule. Il a été décidé d'implanter en PHP/HTML/CSS/SQL la partie front office du site en priorité en suivant la maquette papier (très peu de différences fonctionnelles entre la maquette papier et le site: une information en plus sur la recherche ou un bouton annuler sur la liste des réservations par exemple) et de faire les séances de tests utilisateurs directement sur la maquette du site afin de prendre un peu plus de temps pour la phase d’implantation.

Les tests utilisateurs couvraient un seul scenario : la réservation d'un vol aller/retour pour Marseille↔Amsterdam et ont été conduits avec deux personnes.
Ils ont remonté :

• un problème avec la seule présentation de la page de connexion/identification dans le cas de la réservation qui omet le cas de figure d'une création de compte à partir de ce cas;
• un problème avec la cinématique de réservation qui demande une identification et/ou la création d'un compte avec identification après la recherche sur les vols et ne retourne pas sur la page de recherche tout en perdant les critères de recherche après identification et/ou création d'un compte avec identification;
• un problème de retour sur la page consulté avant identification (le retour se fait sur la page d'accueil par défaut).

La partie back office n'a pas été maquettée. Elle n'a en fait pas dépassé le stade de la conception.

L'IHM suit le principe Gestalt de similitude en mettant les fonctions de même niveau avec la même forme/mise en page. Elle le suit même de manière excessive sur les formulaires en mettant par exemple le champs pour le numéro de rue au même niveau que le champs pour le nom de la rue.
Le menu principal dans l’entête est séquentiel et ne contient que les deux fonctions principales : la recherche et les réservations qui est conditionnelle au statut d’identification du client. Il contient aussi le lien standard vers la page d’accueil.
L’entête contient un lien vers l'espace client et les informations d'identification alignés sur la gauche.
L'intégralité du contenu est centré et s'adapte à la taille de l’écran.

Par manque de temps, un certain nombre d'habillages n'ont pas été implantés :

• la page d'accueil devait contenir des boutons rectangulaires (fait avec CSS, pas un bouton de type formulaire) dans une couleur vive vers les trois fonctions principales à faire dans l'ordre : Se créer un compte → S'identifier → Rechercher un vol;
• le menu dans l’entête aurait du contenir également des boutons au lieu de simples liens;
• la présentation des vols ou des réservations aurait du permettre de trier par clé;
• l'entête aurait du contenir le logo de la compagnie aérienne;
• il aurait été souhaitable d'ajouter le principe proximité aux formulaires, en particulier pour les champs relatifs à l'adresse du client;
• le découpage de la page mêlant verticalité et horizontalité : le menu sur la droite ou la gauche pour laisser plus de place au corps de la page, la section dans l'entête qui contient le lien vers l'espace client et les informations d'identification sur le coté opposé dans le coin haut de l'écran avec une mise en page en rectangle.

La liste n'est pas exhaustive et le choix a été d'implanter les points les plus importants en priorité.

Schéma de relations de la base de données :

AVIONS(NumAv, NomAv, CapAv, VilleAv)
PILOTES(NumPil, NomPil, NaisPil, VillePil)
VOLS(NumVol,VilleD, VilleA, DateD, DateA, #NumPil, #NumAv, CoutVol)
CLIENTS(NumCl, PrenomCl, NomCl, EmailCl, PasswordCl, NumRueCl, NomRueCl, CodePosteCl, VilleCl)
DEFCLASSES(#NumVol, Classe, CoeffPlace, CoeffPrix)
RESERVATIONS(#NumCl, #NumVol, #Classe, NbPlaces)
ADMINISTRATEURS(NumAdm, NomAdm, EmailAdm, PasswordAdm)

Les types des attributs, autres que chaîne de caractères, sont donnés ici :

• Les numéros servant de clé sont des entiers, à l’exception du numéro de vol NumVol qui est une chaîne de caractères commençant par la lettre ’V’.
• CapAv, NaisPil, NbPlaces, NumRueCl, CodePosteCl sont des entiers.
• CoutVol, CoeffPlace et CoeffPrix sont des nombres décimaux : CoeffPlace, dans l’intervalle [0,1], donne le pourcentage de places existant dans la Classe concernée, pourcentage relatif à CapAv, capacité totale de l’avion. CoeffPrix, supérieur ou égal à 1, donne le coefficient multiplicatif à appliquer à CoutVol pour obtenir le prix réel d’un voyage dans la classe voulue. CoutVol est donc le prix minimal d’une place, sur le vol concerné.
• DateD et DateA sont des dates, comportant le jour et l’heure voulue.

La racine du site contient :

• le fichier index.php dont la fonction est de router vers le bon contenu le corps de la page en fonction de la valeur de variable page passée en paramètres dans l'URL et du type de requête HTTP (seul POST ou GET sont pris en compte);
• le répertoire lib qui contient les classes ou fonctions outils;
• le répertoire includes qui contient les fichiers représentants les différents contenus qui seraient affichés via index.php : config.php pour la configuration du site, header.php pour l'entête, header.html pour le code HTML de l'entête, search.php pour le corps de page de recherche, footer.php pour le pieds de page, etc.
• le répertoire styles pour le ou les fichiers CSS de mise en page et forme;
• le répertoire js pour le ou les fichiers contenant le code en javascript.

Il est à noter que le routage dans index.php en cas d'une requête HTTP GET inclura le contenu du fichier include/page.php et en cas d'une requête HTTP POST inclura le contenu du fichier includes/formpage.php.

La liste des pages routées est contrôlée dans le fichier de configuration de l'application pour éviter toutes demandes illégitimes de contenu via le fichier index.php et la variable page.

On trouve dans la plupart des formulaires du site des listes de choix unique à faire parmi du contenu en base. La construction de ces listes s'articule autour d'une requête SQL select sur un seul champs d'une table dont le contenu est rendu unique et qu'on ordonne.

Par exemple pour les villes/aéroports de départ des vols :

SELECT DISTINCT VilleD FROM VOLS ORDER BY VilleD

La fonction recherche est dans les fichiers

• includes/search.php → formulaire html avec pré-remplissage possible;
• includes/formsearch.php → traitement du contenu formulaire de recherche avec également le formulaire de recherche pré-rempli et les résultats de la recherche.

Le contenu du formulaire est soumis à un certain nombre de vérifications avant execution de la requête SQL principale :

• la date de départ est supérieure à la date actuelle;
• la date d'arrivée est supérieure à la date départ;
• etc.

Le traitement s'articule autour de la requête SQL paramétrée :

SELECT VOLS.NumVol AS NumVol, VilleD, DateD, VilleA, DateA, DEFCLASSES.Classe, round(CoutVol*CoeffPrix, 2) AS Prix, CapAv
FROM VOLS JOIN DEFCLASSES ON DEFCLASSES.NumVol = VOLS.NumVol
JOIN AVIONS ON AVIONS.NumAv = VOLS.NumAv
WHERE DateD >= ? AND VilleD = ? AND DateA <= ? AND VilleA = ?
ORDER BY DateD, NumVol, Prix

Les résultats contiennent également le nombre de places disponibles par vol qui sont obtenus par la requête SQL:

SELECT SUM(NbPlaces) AS BookedPlaces FROM RESERVATIONS WHERE NumVol = ?

et le calcul de la différence avec la valeur de CapAv pour chaque vol.

Accueil → includes/home.php.

Espace client → include/account.php et includes/formaccount.php.
Connexion → includes/login.php et includes/formlogin.php.
Déconnexion → includes/logout.php.
Création de compte → includes/register.php et includes/formregister.php
Réservations client → includes/reservations.php et includes/formreservations.php
Réservation → includes/formbooking.php.
Modification réservation → includes/modify.php et includes/formmodify.php

Les requêtes SQL paramétrées se trouvent dans les variables $sql_pquery pour chaque implantation de chaque fonctionnalité.

• Filtrage et validation systématique de toutes valeurs externes au site (résultats d'un formulaire, variable dans l'URL, etc.);
• Utilisation exclusive de requêtes SQL paramétrées via mysqli pour éviter les injections;
• Les pages nécessitant une authentification ont un “page guard” interdisant toute exécution du code.

Le test qui a permis de debugger et stabiliser la partie front office de l'application a été une réservation en partant de zéro (sans compte sur le site) d'un vol aller/retour suivi d'une annulation du retour et de trois modifications de l'aller, une pour le nombre de places et pour la classe et une pour les deux.

Le temps imparti ne m'a permis que d'implanter la partie front office, la partie back office n'ayant pas quitté le stade de la conception.

Certaines fonctionnalités manquent toujours à la partie front office et sont en fait les trois points que les tests utilisateurs ont remontés qui posent tout de même un problème pour faire une réservation en partant de zéro, qui est le cas de figure de base.