Résumé

Dans le cadre de notre projet de fin d’étude à l’Université Saad Dahlab-Blida 1 et en vue de
l’obtention de la licence académique en ingénierie de Système d'informatique et logiciel, nous avons eu
pour but la conception et réalisation d’un site web de réservation hôtel/billet avion /location voiture.

Ce projet a été réaliser en suivant un enchaînement d’étape commençant par la recherche

bibliographique dans laquelle nous avons étudié l’existant et posé notre problématique et objectifs puis
l’étape de conception et modélisation du projet en utilisant quelques diagrammes, afin d’aboutir à une
solution dans le but était de réaliser le site web, enfin l’implémentation tests et validation ou nous avons
concrétisé notre solution et validé ses différents fonctionnements.

Mots Clé

-API.

- Diagrammes.

- Site web.

- Implémentation.

- test.
 Chapter 1 General Introduction
1.1 Project description

Les technologies de l'information et de la communication ont évolué de manière

exponentielle, surtout ces dernières années. Cette révolution a eu un impact significatif

sur les organisations du secteur public et privé. Par ce fait, l'utilisation des systèmes

d'information est devenue très importante et a entraîné l'augmentation des achats &

réservation et différents services à domicile, ainsi les achats en ligne se sont répandus

pour suivre le développement rapide de la technologie et des ventes. Ainsi, nous

pouvons dire que les sites agence voyages comme (ladjar travel) en ligne permettent

d'économiser du temps et des efforts, d'un autre côté, elles évitent les problèmes de

mobilité, et leurs coûts, et facilitent le processus de recherche.Notre application donnera

un autre aspect à l'utilisation de la technologie dans notre vie, les utilisateurs de notre

site web peuvent accélérer le processus de réservation tell services avec des meilleurs

offres parmi plusieurs sites existants dans l’internet.

1.2 Problematic

Les clients/utilisateurs afin de réaliser des réservations pour certain services le

Filtrage des besoins des clients vas durer longtemps (des heures ou des jours) pour
Décider/choisir leurs services en plus les problèmes de mobilité, et leurs coûts.
1.3 Recherches connexes

Navigateur Web : il s'agit simplement d'un "navigateur", c'est une application utilisée

pour accéder aux sites Web et les visualiser. Les navigateurs Web les plus courants

sont Microsoft Edge, Google Chrome, Mozilla Firefox et Apple Safari. La fonction

principale d'un navigateur Web est de rendre le HTML, le code utilisé pour concevoir ou

"baliser" les pages Web [27]. [27]

Internet et World Wide Web : L'internet est un immense réseau d'ordinateurs tous connectés

entre eux. Le World Wide Web (WWW) est une collection de pages web trouvées sur ce réseau

d'ordinateurs. Votre navigateur utilise l'internet pour accéder au web. [14]

L'e-commerce : connu sous le nom de commerce électronique, désigne l'achat et la vente de

biens ou de services par le biais d'Internet, ainsi que le transfert d'argent et de données pour

exécuter ces transactions. [15]

Réservation en ligne : est la fonction principale de la plateforme de négociation du site, Les

visiteurs peuvent se connecter à l'Internet par l'intermédiaire de l'ordinateur dans le réseau de

l'entreprise, puis accéder au site réservation en ligne (dans notre cas c’est ledjar travel), puis

sélectionné le service et entré des informations concernant ce services et finalement cliqué

recherche puis payé.

 Quelques sites existants :

-booking.

-blabla cars.

1.4 Le système proposé

La réservation en ligne a brisé le mode de gestion des réservation traditionnelles, tant que vous

avez un ordinateur, vous pouvez faire des réservations et achats en tout lieu et n'import ou, en

économisant le temps et l'effort, en réduisant le temps de la sélection des services de manière

efficace. Le système de la réservation en ligne est basé sur le principe de la commodité et du

service aux personnes.

Nous avons donc choisi le système suivant pour notre site des réservations en ligne :

Notre application aura deux instances, l'une fonctionnant du côté serveur, et l'autre fonctionnant

du côté client représenté par une page Web.

Les clients dans ce cas naviguent sur le site web, et recherchent n'importe quel service, et

taper les informations concernant ce service puis clique sur rechercher, le site web permet au

client de se connecter s'il a un compte valide ou d'en créer un, puis achète le service.
1.5 Objectives du site web

Notre application web est censée être capable de :

- Faciliter le filtrage et la recherches des services avec leurs meilleurs offres.

-Rendre le client plus confortable. Il pourra effectuer toutes les démarches en utilisant
simplement son ordinateur ou son smartphone.

- Rendre l'administrateur plus confortable en rendant tout gérable depuis son tableau de bord.

1.6 Structure du rapport

Le deuxième chapitre donne un aperçu de l'analyse et de la conception du projet, les méthodes de

développement et les besoins fonctionnels et non fonctionnels, les types

De diagrammes (classe), nous parlerons également de la base de données sous forme d’API.

La réalisation de notre projet fera l'objet du troisième chapitre, les outils ainsi

Que les langages de programmation utilisés, nous expliquerons le fonctionnement de notre

application à l'aide de quelques captures d'écran. Nous conclurons notre thèse par l'exposition de
l'ensemble des connaissances acquises lors de la réalisation de notre projet, nous exposerons vers
la fin une conclusion générale.
 Chapter 2 Analysis and design
2.1 Introduction
Une étape essentielle de tout cycle de développement logiciel ou conceptuel est la
réalisation d'une pré-étude. Le but de cette phase est de comprendre le contexte du système. Il
s'agit de clarifier les besoins fonctionnels et non fonctionnels, de faire apparaître les acteurs et
d'identifier les cas d'utilisation. Dans ce chapitre, nous allons essayer d'exprimer les besoins sous
forme de quelques diagrammes de l’API.

2.2 Development

Afin de mener à bien notre projet, nous avons suivi l'approche agile

Figure1 l'approche agile

Dans la suite de ce rapport, nous détaillerons chaque phase du cycle de vie, en mentionnant les

méthodes et les outils utilisés pour atteindre nos objectifs.

2.2.1 Pourquoi avons-nous utilisé l'approche agile ?

1-Flexibilité

2-Amélioration de la visibilité/prévisibilité du projet

3-Augmentation de la vitesse d'exécution

4-Réduction des risques

5-Meilleure qualité du produit

2.3 Spécification des besoins

La spécification des exigences ou spécification des besoins est la phase initiale de

tout développement d'application dans laquelle nous allons identifier les besoins de notre

application. Nous distinguons les besoins fonctionnels qui présentent les caractéristiques

attendues de notre application et les besoins non fonctionnels pour éviter le développement d'une

application insatisfaisante.

2.3.1 Spécification des exigences fonctionnelles

Après une étude détaillée, cette partie est réservée à la description des besoins

fonctionnels, des différents acteurs de l'application. Ces besoins sont regroupés dans les

diagrammes des cas d'utilisation.

Cette application doit principalement couvrir les besoins fonctionnels suivants :

- Voir les details.

-gestion des réservations.

-Email utilisateur-admin.

- Gérer les commandes.

-Gestion des administrateurs.

-Gestion du courrier électronique.

2.3.2 Spécification des exigences non fonctionnelles

Les besoins non fonctionnels décrivent l'ensemble des contraintes techniques,

ergonomiques et esthétiques auxquelles le système est soumis pour sa réalisation et pour son bon

fonctionnement.

Les principaux besoins non fonctionnels de notre application sont les suivants :

- La sécurité : l'application doit respecter la confidentialité des données.

- La fiabilité : les données fournies par l'application doivent être fiables.

- La confidentialité : l'application doit respecter la confidentialité des données.

- Interface utilisateur et expérience utilisateur agréables.

- Responsive design pour tous les appareils.

-Le code est clair pour nous permettre des modifications et améliorations ultérieures.

-Page d'inscription et de déconnexion.

-Modification du compte et du mot de passe.

-Gestion des feedbacks/boîtes/termes.

2.4 Méthodologie
 Chapter 3 Application Implementation
3.1 Introduction
Maintenant, nous avons fait une meilleure conception, bien adaptée aux besoins de
notre sujet d'étude. Nous avons fait une étude approfondie de notre problème. Il est donc bien
analysé.

Ce chapitre est consacré à la phase de réalisation. C'est ici que nous allons parler de
l'environnement de notre développement logiciel et matériel, des outils utilisés, des langages de
programmation, et du système de base de données utilisé. Ensuite, nous expliquerons la méthode
de notre développement et nous terminerons par des captures d'écran des principales interfaces de
notre application.

3.2 Development Environment

3.2.1 Material Environment
For the realization of our project, we used a Lenovo computer characterized by:

 Operation System: Windows 10.

 Processor: Intel R Core-TM i5- 4400U CPU 1.70 GHz.
 Ram: 8GO.
 Hard Disk: 500GO.

3.2.2 Environnement logiciel

Visual Studio Code est un éditeur de code source léger mais puissant qui fonctionne sur votre
bureau et est disponible pour Windows, MacOS et Linux. Il est livré avec un support intégré pour
JavaScript, Typescript et Node.js et possède un riche écosystème d'extensions pour d'autres
langages (tels que C++, C#, Java, Python, PHP, Go) et moteurs d'exécution (tels que .NET et
Unity). [9]

HTML5 est un langage informatique conçu pour permettre la création de sites Web. Ces sites
peuvent ensuite être consultés par toute autre personne connectée à l'Internet, les bases étant
accessibles à la plupart des gens en une seule séance ; il est assez puissant dans ce qu'il permet de
créer. [3]

CSS3 signifie "Cascading Style Sheets" (feuilles de style en cascade), l'accent étant mis sur le
"style". Le langage HTML est utilisé pour structurer un document Web (en définissant des
éléments tels que les titres et les paragraphes). [4]

Bootstrap3.3.7 est un cadre de développement frontal gratuit et open source pour la création de
sites et d'applications Web.
De sites Web et d'applications Web. Le cadre Bootstrap s'appuie sur HTML, CSS et JavaScript
(JS) pour faciliter le développement de sites et d'applications réactifs et axés sur le mobile [7].

JavaScript1.8.5 est un langage de script utilisé pour créer et contrôler le contenu dynamique d'un
site Web, c'est-à-dire tout ce qui bouge, se rafraîchit ou change sur votre écran sans que vous ayez
à recharger manuellement une page Web. [6]

Xampp3.2.4 X signifie Cross-platform, (A) Apache server, (M) Maria DB, (P) PHP et

(P) Perl est un logiciel open source développé par des amis d'Apache. Le progiciel XAMPP
contient des distributions Apache pour le serveur Apache, Maria DB, PHP et Perl. Il s'agit
essentiellement d'un hôte local ou d'un serveur local. Ce serveur local fonctionne sur votre propre
ordinateur de bureau ou portable. [5]

PHP7.2.28 est un langage de script côté serveur. Il est utilisé pour développer des sites Web
statiques ou des sites Web dynamiques ou des applications Web. PHP est l'acronyme de
Hypertext Pre-processor, qui signifiait auparavant Personal Home Pages. [25]

L'API Google est une API JSON de recherche personnalisée qui vous permet de développer des
sites Web et des applications pour récupérer et afficher les résultats de recherche de Google
Custom Search de manière programmatique. Avec cette API, vous pouvez utiliser des requêtes
RESTful pour obtenir des résultats de recherche Web ou de recherche d'images au format JSON.
[17]

Navicat est une suite logicielle graphique de gestion et de développement de bases de données
produits par PremiumSoft CyberTech Ltd. Pour MySQL, MariaDB, Oracle, SQLite, PostgreSQL
et Microsoft SQL Server.[7]

SQL est le langage le plus populaire pour ajouter, accéder et gérer le contenu d'une base de
données. Il est surtout connu pour sa rapidité de traitement, sa fiabilité éprouvée, sa facilité et sa
flexibilité d'utilisation.
MySQL est un élément essentiel de presque toutes les applications PHP open source. [8]

Les approches d'accès aux API.

 API privées:
L'API n'est utilisable qu'en interne. Cette approche permet de garder un
Contrôle total Sur l’API.

 API partenaires:

L'API est partagée avec certains partenaires de l'entreprise. Cette approche

Peut générer de nouveaux flux de revenus sans compromettre la sécurité.

 API publiques:

L'API est accessible à tous. Cette approche autorise les tiers à développer
Des applications qui interagissent avec votre API et peut devenir source
D’innovations.
Comment l’API favorisent-elles l'innovation.

En rendant vos API accessibles à vos partenaires ainsi qu'aux tiers, vous
pouvez :

 Générer de nouveaux canaux de revenus ou étendre ceux qui existent

déjà.
 Étendre la portée de votre marque.
 Stimuler l'innovation Open Source ou améliorer l'efficacité grâce au
développement et à la collaboration externes.

Intéressant, non ? Mais quel est le rôle des API dans tout ça ?

Reprenons notre exemple du distributeur de livres.

Imaginez qu'un partenaire de l'entreprise développe une application qui

permet aux clients de localiser les livres qu'ils cherchent dans les rayons.

En améliorant l'expérience client, cette application va attirer d'autres clients

dans la librairie, elle-même cliente du distributeur, qui en fin de compte aura
étendu son canal de revenus.

Une entreprise tierce peut aussi utiliser une API publique pour développer une
application afin que les clients puissent acheter des livres directement auprès
du distributeur, sans passer par la librairie.
Dans ce cas, le distributeur aura ouvert un nouveau canal de revenus.

Une entreprise peut tirer parti du partage de ses API avec certains de ses
partenaires ou avec le monde entier.

Chaque partenariat vous permet d'étendre la notoriété de votre marque en

parallèle de vos campagnes marketing.

En rendant vos technologies publiques, avec une API publique par exemple,
vous encouragez les développeurs à créer un écosystème d'applications
autour de votre API.

Plus les gens utilisent vos technologies, plus ils sont susceptibles de faire
affaire avec vous.

Vous pouvez ainsi obtenir des résultats aussi inattendus qu'intéressants en

ouvrant l'accès à vos technologies et ces résultats peuvent parfois bouleverser
un secteur tout entier.

Dans le cas de notre distributeur de livres, de nouvelles entreprises, comme

un service de location de livres, peuvent provoquer un changement
fondamental dans son fonctionnement.

Les API publiques et partenaires vous permettent de profiter des innovations

d'une communauté de développeurs plus large.

Les idées novatrices peuvent germer n'importe où. Les entreprises doivent se
tenir au courant des changements qui s'opèrent sur leur marché et se préparer
à y faire face.

C'est là que les API interviennent.

API distantes.

Les API distantes sont conçues pour interagir via un réseau de

communication.

Ici, « distant » signifie que les ressources manipulées par l'API ne se trouvent
pas sur l'ordinateur qui formule la requête. Le réseau de communication le
plus fréquemment utilisé étant Internet, la plupart des API sont conçues sur la
base des normes Web.

Toutes les API distantes ne sont pas des API Web, mais on peut supposer
que toutes les API Web sont distantes.

Les API Web utilisent en général le protocole HTTP pour leurs messages de
requête et fournissent une définition de la structure des messages de réponse.
Les messages de réponse se présentent la plupart du temps sous la forme
d'un fichier XML ou JSON.

Ces deux formats sont les plus courants, car les données qu'ils contiennent
sont faciles à manipuler pour les autres applications.

SOAP ET RESET.

Pour standardiser l'échange des informations entre les API toujours plus nombreuses, il
a fallu développer un protocole : le « Simple Object Access Protocol », ou SOAP.

Les API conçues d'après le protocole SOAP utilisent le format XML pour leurs
messages et reçoivent des requêtes via HTTP ou SMTP.

SOAP a pour objectif de simplifier l'échange des informations entre les applications qui
s'exécutent dans des environnements différents ou qui ont été écrites dans des
langages différents.

Le « Representational State Transfer », ou REST, est une autre tentative de

normalisation.

Les API Web qui respectent les contraintes de l'architecture REST sont appelées API
RESTful.

Ces deux éléments diffèrent sur un point fondamental : SOAP est un protocole, alors
que REST est un style d'architecture. Cela signifie qu'il n'existe aucune norme officielle
qui régit les API Web RESTful.

Selon la définition proposée par Roy Fielding dans sa thèse « Architectural Styles and

the Design of Network-based Software Architectures », les API sont RESTful tant
qu'elles respectent les six contraintes de conception d'un système RESTful :

 Une architecture client-serveur : une architecture REST est

composée de clients, de serveurs et de ressources et elle traite les
requêtes via le protocole HTTP.
 Un serveur sans état : le contenu du client n'est jamais stocké sur le
serveur entre les requêtes. Les informations sur l'état de la session sont,
quant à elles, stockées sur le client.

 Une mémoire cache : la mise en mémoire cache permet de se passer

de certaines interactions entre le client et le serveur.

 Un système à couches : des couches supplémentaires peuvent

assurer la médiation dans les interactions entre le client et le serveur.
Ces couches peuvent remplir des fonctions supplémentaires, telles que
l'équilibrage de charge, le partage des caches ou la sécurité.

 Code à la demande (facultatif) : un serveur peut étendre les

fonctionnalités d'un client en lui transférant du code exécutable.

 Interface uniforme : cette contrainte est capitale pour la conception des

API RESTful et couvre quatre aspects différents :

o Identification des ressources dans les requêtes : les

ressources sont identifiées dans les requêtes et sont séparées
des représentations retournées au client.

o Manipulation des ressources par des représentations : les

clients reçoivent des fichiers qui représentent les ressources. Ces
représentations doivent contenir suffisamment d'informations pour
être modifiées ou supprimées.
 o Messages autodescriptifs : tous les messages renvoyés au
client contiennent assez d'informations pour décrire la manière
dont celui-ci doit traiter les informations.

o Hypermédia comme moteur du changement des états

applicatifs : après avoir accédé à une ressource, le client REST
doit être en mesure de découvrir toutes les autres actions
disponibles par des hyperliens.

Ces contraintes peuvent sembler difficiles à appliquer, mais dans les faits,
elles le sont moins qu'un protocole. C'est pour cette raison que les API
RESTful sont en train de prendre le pas sur les API SOAP.

Ces dernières années, la spécification Open API s'est imposée comme la

norme commune pour définir les API REST. La norme Open API permet aux
développeurs de créer des interfaces d'API REST de manière à ce que les
utilisateurs puissent les comprendre avec un minimum d'approximation.

SOAP ou REST

De nombreux systèmes d'anciennes générations reposent encore sur le protocole

SOAP. REST est arrivé plus tardivement et est souvent considéré comme une solution
plus rapide pour des scénarios basés sur le web.

REST est un ensemble de recommandations qui permet une mise en œuvre flexible,
tandis que SOAP est un protocole avec des exigences spécifiques comme l'envoi de
messages au format XML.

Les API REST sont plus légères et donc plus adaptées aux concepts récents tels que
l'Internet des objets (IoT), le développement d'applications mobiles et l'informatique
sans serveur.

Les services web SOAP intègrent des spécifications de sécurité et de conformité des
transactions qui répondent aux besoins de nombreuses entreprises, mais qui les
rendent également plus lourds.
 De plus, de nombreuses API publiques, telles que l'API Google Maps, suivent les
recommandations REST.

Architectures SOA et de micro services.

Figure1 : SOA

Les deux approches architecturales qui utilisent le plus les API distantes sont
l'architecture orientée services (SOA) et l'architecture de microservices. La SOA est
l'approche la plus ancienne.

Elle visait à l'origine à améliorer les applications monolithiques. Par définition, une
application monolithique fait tout.

Mais certaines fonctions peuvent être fournies par d'autres applications faiblement
couplées via un modèle d'intégration, comme une ESB (Enterprise Service Bus).

Si l'architecture SOA est plus simple qu'une architecture monolithique sous bien des
aspects, elle peut potentiellement provoquer des changements en cascade au sein de
l'environnement si les interactions entre les différents composants ne sont pas
parfaitement comprises.

En complexifiant l'environnement, l'architecture SOA réintroduit une partie des

problèmes qu'elle cherchait à résoudre.
Les architectures de microservices fonctionnent d'une manière très similaire, dans le
sens où elles utilisent des services faiblement couplés.

Figure 2 : microservices

Par contre, elles poussent la déstructuration de l'architecture classique encore plus loin.

Les services qui composent l'architecture de microservices utilisent une structure de

messagerie commune, telle que les API RESTful.

Ils se servent des API RESTful pour communiquer entre eux simplement, sans convertir
leurs données ni recourir à des couches d'intégration supplémentaires.

L'utilisation des API RESTful permet et favorise même l'accélération de la distribution

des nouvelles fonctions et mises à jour.

Chaque service est distinct. Vous pouvez remplacer, améliorer ou supprimer chacun
d'entre eux sans affecter les autres services de l'architecture.
Cette architecture légère vous aide à optimiser les ressources distribuées ou cloud et à
faire évoluer chaque service de façon dynamique.

L'API modern.

Au fil des années, la notion d'« API » a souvent décrit toutes sortes d'interfaces
génériques de connectivité à une application. Cependant, plus récemment, l'API
moderne a acquis certaines caractéristiques qui la rendent extraordinairement précieuse
et utile :

 Les API modernes adhèrent à des normes (généralement HTTP et REST)

pratiques pour les développeurs, facilement accessibles et largement comprises.
 Elles sont davantage considérées comme des produits que comme du code.
Elles sont conçues pour être utilisées par des publics spécifiques (comme les
développeurs mobiles), sont documentées et font l'objet de versions permettant
aux utilisateurs d'avoir de la visibilité en termes de maintenance et de cycle de
vie.
 Comme elles sont beaucoup plus normalisées, elles sont soumises à une
discipline beaucoup plus stricte en matière de sécurité et de gouvernance. Leurs
performances et leur mise à l'échelle sont également contrôlées et gérées.
 Comme tout autre logiciel en production, l'API moderne possède son propre cycle
de développement de logiciels (SDLC) incluant la conception, les tests, le
développement, la gestion et les versions. Les API modernes sont également
bien documentées concernant la consommation et la gestion des versions.
Sécuriser un site web
Protection contre les menaces

Les sites web sont par nature des éléments très exposés du système

D’information. Leur sécurisation revêt une grande importance, et ce à

plusieurs titres.

Les menaces les plus connues pesant sur les sites web sont les défigurations et les
dénis de service.

Une défiguration est une attaque par laquelle une personne

Malveillante modifie le site pour remplacer le contenu légitime par un contenu

qu’il choisit, par exemple pour relayer un message politique, pour dénigrer le

Propriétaire du site ou simplement, pour revendiquer son attaque comme preuve

d’un savoir-faire. Un déni de service a quant à lui pour objet de rendre

Le site attaqué indisponible pour ses utilisateurs légitimes. Dans les deux cas,
l’impact sur le propriétaire du site est évidemment un déficit d’image et, pour

Le cas d’un site servant de support à une activité lucrative, un manque à gagner.

Il ne faut toutefois pas négliger les scénarios d’attaques plus insidieux.

Il est possible qu’un individu malveillant se serve d’un site web comme une

Porte d’entrée vers le système d’information de l’hébergeur ou, plus généralement,

de l’entité à qui appartient le site.

Par ailleurs, un site peut être utilisé comme relai dans une attaque élaborée
Vers un système tiers ou comme dépôt de contenus illégaux, ces situations étant
susceptibles de mettre l’exploitant légitime du site en difficulté.

Enfin, une attaque sur un site peut aussi viser à tendre un piège aux clients
habituels de ce site, qui sont souvent les employés du propriétaire du site ou de ses
partenaires.

Ainsi, l’externalisation de l’hébergement d’un site ne permet Pas de transférer

l’ensemble des risques d’intrusion au système d’information de l’hébergeur.

Toutes ces attaques ont en commun de rechercher, contrairement à celles évoquées

plus haut, une certaine discrétion et peuvent par conséquent rester insoupçonnées
pendant de longues périodes.

La protection contre ces menaces passe à la fois par des mesures préventives et par
des mécanismes permettant de détecter les tentatives d’attaques.

La sécurité fournis par l’API.

Les données de votre téléphone ne sont jamais totalement visibles pour le

serveur. De même, le serveur n'est jamais totalement visible pour votre
téléphone.

À la place, ils communiquent par petits paquets de données et ne

partagent uniquement ce qui est nécessaire, comme lorsque vous

Commandez un plat à emporter. Vous dites au restaurant ce que vous

aimeriez manger, il vous indique ce dont il a besoin en retour et vous
obtenez votre repas.

Les API sont devenues si précieuses qu'elles représentent une part

importante des revenus de nombreuses entreprises.
 De grandes entreprises comme Google, eBay, Salesforce.com, Amazon et
Expedia ne représentent qu'une infime partie des entreprises qui tirent profit
de leurs API.

L'« économie des API » correspond au marché des API.