Dossier de projet O'vacances, planificateur de vacances - Quentin Brohan

Dossier de projet
O’vacances, planificateur de vacances

Projet réalisé dans le cadre de la présentation au Titre Professionnel Développeur Web & Web Mobile

Présenté par Référent de formation Organisme de formation
Quentin BROHAN M. Fabio CERQUEIRA École O’Clock
Promotion Excalibur - 2020

Sommaire

Sommaire 2 V. Organisation de l’équipe 27
Remerciement 4 Présentation de l’équipe 28
 Répartition et détails des rôles 29
I. Introduction à O’Vacances 5 Organisation de travail 30
Introduction 6
 Outils utilisés 31

II. Résumé du projet 7 Programme des sprints 32-33
O’Vacances c’est quoi ? 8
 VI. Compétences du référentiel 34
III. Cahier des charges 9 Partie front-end :
Conceptualisation de l’application : CP1 - Maquette une application . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
 Fonctionnalités du projet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 CP2 - Interface statique et adaptable. . . . . . . . . . . . . . . . . . . . . . . . 36
 Minimum Viable Product. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 CP3 - Interface web dynamique. . . . . . . . . . . . . . . . . . . . . . . . . 38-39
 Workflow de l’application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Partie back-end :
Utilisateur et User Stories : CP5 - Créer une base de données. . . . . . . . . . . . . . . . . . . . . . . . 40-41
 Public visé et rôles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 CP6 - Composants d’accès aux données. . . . . . . . . . . . . . . . . . . . 42-44
 User Stories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 CP7 - Partie back-end d’une application web. . . . . . . . . . . . . . . . . 45-46
Mise en place de l’application :
 VII. Production 47
 Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
 Réalisations personnelles :
 MCD/Modèle Conceptuel de Données . . . . . . . . . . . . . . . . . . . . . . . 16
 Wireframe page voyage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48-52
 Dictionnaire de données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
 Mise en place RTK & RTK Query. . . . . . . . . . . . . . . . . . . . . . . . . 53-54
 MLD/Modèle Logique - MPD/Modèle Physique. . . . . . . . . . . . . . . . . . 18
 Composants réutilisables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55-56
 Wireframes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
 Jeu d’essai :
 Charte graphique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
 Application et composant. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Roadmap 21
 VIII. Veille et troubleshooting 59
IV. Spécifications techniques 22 Veille technologique :
Versioning 23
 Cas n°1 : Cookies vs token JWT. . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Technologies du front-end 24
 Cas n°2 : Sensibilité et validation mot de passe. . . . . . . . . . . . . . . . . . 61
Technologies du back-end 25
 Résolution de problème :
Sécurité de l’application 26
 Déploiement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
 Restitution des dates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Problématique :
 Recherche et traduction d’un extrait (dates). . . . . . . . . . . . . . . . . . . 64

IX. Conclusion 65

X. Annexes 66
User Stories 67
Wireframes :
 Landing page (Home Visitor). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
 Home user. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
 Trip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
 Activités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Profile 72
MCD 73
MLD 74
Dictionnaire de données 75
Routes (endpoints) 76
Diagramme du state de l’application 77
Traduction d'un texte en anglais (Moment.js) 78-79
Screenshots de l'application 80-83

 3

Remerciement

 Je voudrais tout d'abord remercier notre référent de formation M. Fabio CERQUEIRA
 pour sa bienveillance et sympathie tout au long de notre formation.
 Je tiens également à remercier Audrey, sans laquelle ce projet challengeant
 n'aurait pas eu lieu, ainsi que mes autres camarades membres de l'équipe
 O'Vacances : Cécilia, Alexandre et Loïc; les membres et professeurs de ma
 promotion Excalibur au sein de ces 6 mois intensifs chez O'Clock, où j'ai appris
 et continuerai d'apprendre et penser comme un développeur, mais aussi pour
 la qualité des cours, les valeurs et relations entretenues entre tous, et toute la
 joie apportée aussi bien sur le plan personnel que professionnel.

4

I. INTRODUCTION À O’VACANCES

 5

Introduction

 Après un parcours dans l’imprimerie, d’infographiste d’études à imprimeur, j’ai souhaité me rapprocher de mon parcours
 initial tout en élargissant mon champ de compétences et participer activement au futur du web, qui de par le dynamisme
 des contenus, l’interaction utilisateur et l’animation sont des points importants auxquels je souhaitais prendre part et
 qui n’existaient pas dans le domaine du print.
 C’est ainsi que j’ai découvert O’Clock et sa formation diplômante de développeur web intensive de 6 mois, où j’ai pu
 découvrir et apprendre le métier de développeur web via l’intégration HTML/CSS, la programmation avec PHP et le
 concept de Programmation Orientée Objet, la manipulation du DOM avec Javascript, la gestion d’une base de données
 et la création d’une API, les bonnes pratiques web ; ainsi que gérer un déploiement et réaliser les documents propres à
 un projet. Et à terme de cette formation, l’apprentissage d’un framework au choix : React, Symfony ou Wordpress d’un
 mois avant l’étape finale scellant la fin de notre formation.
 Dans le cadre de la fin de notre formation chez O’Clock, et en vue du Titre Professionnel Développeur Web & Web
 Mobile, nous avons dû réaliser en équipe entre membres de notre promotion Excalibur, un projet dit d’« Apothéose ».
 Le but ? Développer un site web de A à Z, en un mois. Au cours du mois de spécialisation avant le projet, un repo
 GitHub dédié a été ouvert pour que chaque étudiant de la promo puisse y placer ses idées de projet.
 Au cours de ce dossier, je vais vous présenter le projet O’Vacances, une application de planification de voyages, de
 l’idée initiale à la rédaction des documents de projet, en passant par la réalisation et les problèmes rencontrés ainsi
 que leur solution.

6

II. RÉSUMÉ DU PROJET

 7

O’Vacances c’est quoi ?

 Introduction
 Toute personne étant déjà partie en vacance a déjà connu l’embarras des
 nombreuses informations échangées lors de la préparation et le déroulement
 du voyage, via différents canaux utilisés (à l’oral, par SMS, sur les réseaux
 sociaux…). On l’a compris, certaines informations finissent par se perdre, ou
 de n’être accessible que par une seule personne.
 Soucieux de pouvoir partir en toute sérénité, c’est ainsi qu’est né O’Vacances,
 une application web d’aide à l’organisation de vacances, que ce soit à plusieurs,
 en famille, entre amis ou même pour les voyageurs solitaires. L’application
 est conçue en mobile-first pour faciliter son utilisation lors des moments des
 prises de notes, mais également des déplacements.

 Objectif
 L’objectif d’O’Vacances et de centralisé l’accès aux informations (dates, lieu,
 activités…) d’un voyage et permettre ainsi à chacun de les consulter, afin d’être
 à jour sur les activités prévues tout en les laissant disponibles et modifiables
 par les participants tout comme les suggestions et dernières infos partagées.
 Dans une version plus avancée, il est prévu de pouvoir noter dans un agenda
 les activités planifiées, ainsi que de gérer les comptes à l’aide d’une solution
 de paiement intégrée.

8

III. CAHIER DES CHARGES

 9

Conceptualisation de l’application :
 Fonctionnalités du projet

 Les spécifications fonctionnelles sont une section du cahier des charges ou un document à part entière qui spécifie,
 décrit, précise les fonctionnalités du site, de l’application ou du logiciel en question.
 Elles ont été définies en équipe lors du premier sprint selon le cahier des charges et le workflow (arborescence) du site.

 Page principale (visiteur) Page de création de voyage
 – Landing page du site avec capture d’écrans et description – Formulaire de création d’un voyage avec upload d’une
 des différentes fonctionnalités photo pour illustrer le voyage
 – Accès aux pages « À propos », « Contact » et « Qui sommes-
 nous » Page du voyage
 – Bouton de connexion utilisateur – Voir les informations du voyage (titre, dates, lieu, partici-
 pants, mot de passe)
 Page principale (utilisateur) – Voir ses disponibilités et celle des autres, ajouter/modifier
 – Accès à tous ses voyages prévus et passés les siennes dans un calendrier
 – Accès aux pages public – Vu et accès aux activités
 - Accès à son profil – Vu et ajout de suggestions
 – Bouton de création d’un voyage et d’une activité
 Page de login – Possibilité de modifier/supprimer ses activités et suggestions
 – Formulaire de connexion Page « Qui sommes-nous ? » (visiteur et utilisateur)
 – Accès à « Mot de passe oublié » – Présente les personnes qui ont contribué au projet, leurs
 rôles, ainsi que leurs moyens de contact.
 Page de création de comptes
 – Formulaire de création de comptes Page contact pour support technique
 – Formulaire de contact pour assistance
 Profil utilisateur
 – Visualisation de ses informations personnelles Page mentions légale
 – Possibilité de modifier son avatar et ses informations – Mentions légales
10

Conceptualisation de l’application :
Minimum Viable Product

Le produit minimum viable (MVP en anglais) est la version d’un produit qui permet d’obtenir un maximum de retours
client avec un minimum d’effort.
Nous avons défini en équipe le minimum requis pour la première release d’O’Vacances. Celui-ci est séparé selon si
l’utilisateur est connecté ou non.
Disponible sans authentification
– Landing page (visiteur) présentant l’application et ses fonctionnalités
– Page de création de comptes
– Page de login
– Page « Qui sommes-nous ? » (visiteur et utilisateur) : présente les personnes qui ont contribué au projet.
– Page de contact
– Page de mentions légales

Disponible seulement après authentification
– Page d’accueil après connexion : accès à tous les voyages à venir et passés (et non supprimés)
– Accès au profil utilisateur avec possibilité de modification des informations et de l’avatar
– Page de création de voyage (formulaire)
– Page du voyage : titre, description, dates, participants et leurs disponibilités des participants, zone géographique, lien
 vers la page des activités, zone suggestions, lien et mot de passe à partager pour l’accès et l’inscription des autres
 participants du voyage
– Page répertoriant la totalité des activités proposées dans un voyage

Évolution
Nous n'avons pas eu le temps de mettre en place le système de mailing utilisé pour les invitations de voyage/contact/
mot de passe oublié, mais ceux-ci restent d'actualité pour les futures versions de l'application. Nous avons également
prévu l'implémentation d'un système de cartographie pour les lieux et activités de voyage, d'un calendrier/planificateur
pour le suivi des activités, des suggestions sous forme de threads pour grouper les conversations, mais également l'in-
tégration d'une solution de paiement et d'un inventaire des objets/équipements/outils apportés par chacun. 11

Conceptualisation de l’application :
 Workflow de l’application

 Toujours au sein du premier sprint (0) et avec la participation de toute l’équipe.
 Nous avons réalisé à l’aide des informations du cahier des charges le workflow
 (arborescence) du site à l’aide du site web diagrams.net.
 Ce schéma représente les différentes
 pages qui composeront le site, liées Landing page
 entre elles et hiérarchisées par niveaux
 de profondeur.

 A propos Contact

 Connexion Inscription

 Accueil connecté

 Profil utilisateur Page du voyage Création d'un voyage

 Activités du voyage

12

Utilisateur et User Stories :
Public visé et rôles

Afin de concevoir O’Vacances, il a été nécessaire de réaliser une étude de
marché afin de connaître le public visé par notre application. Ces données sont
nécessaires pour comprendre les besoins du public, ses attentes et l’intérêt
qu’il pourrait porter à notre projet.
On retrouve ici :
• différents types de voyageurs, partant :
 - entre amis
 - en famille
 - solitaire
• -un âge des voyageurs entre 16 ans et +65 ans. Donc des personnes ayant
 connaissance ou très peu de l’outil informatique.

Rôles utilisateurs
On retrouve ici 2 types d’utilisateurs sur notre application :
Visiteur/utilisateur non connecté : il a accès à la landing page du site décri-
vant l’application, les pages d’inscription et connexion utilisateur, ainsi que les
pages de contact, présentation de l’équipe du projet et les mentions légales.
Utilisateur/utilisateur connecté : il a accès à toutes les fonctionnalités pré-
cédemment citées du site. Il peut également créer ou rejoindre un voyage,
ajouter, modifier, supprimer les informations qui composent ce dernier ainsi
que ses activités et suggestions. Il peut également modifier les informations
de son profil.

 13

Utilisateur et User Stories :
 User Stories

 Aux côtés du Product Owner, nous (toute l’équipe) avons aidé à la rédaction des User Stories tout en veillant à leur
 cohérence.
 Une User Story est une description simple et compréhensible d’une fonctionnalité. Elle se compose d’un titre explicite,
 d’une phrase narrative structurée. Cette formulation permet au Product Owner d’apporter une vision orientée client
 et d’identifier
 User storiesprécisément la fonctionnalité et le bénéfice attendu.
 Extrait des users Stories pour la page d’accueil en tant que visiteur et utilisateur :
 Home

 As a I want So that

 Visitor Be able to see on the landing page what's the See the meaning of the website
 subject of the website and the functionalities of and help me decide if I want to
 the app use it

 Visitor Be able to register as a user Use listed functionalities

 Visitor Be able to login as a user Access to my trips

 Visitor Be able to access the "Team" page Access to info and contact of
 the creator of the app

 Visitor Be able to contact the administrators of the app Contact in case of trouble or bug

 User

 As a I want So that

14

 User Consult my trips See my registered trips and access to them

Mise en place de l’application :
Routes

Les routes représentent ici les endpoints accessibles de notre application, car nous utilisons Symfony en mode API REST.
Symfony ici est utilisé comme un CRUD pour l’accès aux données uniquement, la vue se faisant dans la partie front
grâce à React.
On y retrouve :
• URL : endpoint, chemin d’accès à la route
• HTTP Method : chaque requête effectuée devra décrire correctement l’action qu’elle souhaite effectuer auprès du
 serveur. Si ce n’est pas correct, le serveur vous renverra une erreur. Il y a 5 actions possibles (Get, POST, PUT &
 PATCH, DELETE)
• Controller : gère l’aspect dynamique de l’application à partir de l’action demandée (requête utilisateur), il récupère
 les données (avec le Model) les injecte dans la vue adéquate, et envoie la réponse produite. (selon l’implémentation,
 parfois c’est la vue qui renvoie elle-même la réponse)
• Method : action applicable à un objet. Il s’agit en fait de fonctions qui peuvent prendre ou non des paramètres et
 retourner ou non des valeurs / objets.
• Title : Titre de la route
• Content : Contenu de la route Routes
• Comment : Commentaire

 URL HTTP Controller Method Title Content Comment
 Method

 / GET MainController home Accueil Presentation and functionalities of -
 the application

 /legals-mentions GET MainController legalMentions Mentions légales Privacy policies, Abuse or
 complaints contact information,
 Terms and conditions of use,
 Copyrights notice

 /about GET MainController about À propos de About the team -

 Extrait du document des routes. /login POST UserController login Rapport User loging -
 Voir annexe version complète.
 /login GET UserController login Rapport User loging -
 15
 /logout POST UserController logout Déconnexion User logout -

 /signin POST UserController signin Une inscription User inscription -

Mise en place de l’application :
 MCD/Modèle Conceptuel de Données

 Aussi appeler Modèle Entité-Association. USER ACTIVITY

 email title
 Cette modélisation des données permet de représenter de façon SUGGESTED BY
 lastname
 0,N PROPOSED BY
 description
 BELONG TO

 rigoureuse un système de données, ou système d’information, 0,N firstname 1,1 category 1,1
 password start_date
 sous forme d’entités et des relations qui les lient. avatar 0,N end_date

 0,1 1,1
 Avant de réaliser le dictionnaire de données, nous pouvons :
 HAVE
 • Dessiner nos entités représentées par un rectangle.
 • Répartir leurs attributs : les données qui les concernent sont 1,1 1,N 0,N
 listées sous le nom de l’entité. SUGGESTION DISPONIBILITY CATEGORY
 PARTICIPATE
 • Définir un (ou plusieurs) attribut qui identifie l’entité de manière title start_date name
 description end_date picture
 unique : le déterminant (ou identifiant, discriminant) qui 1,N
 1,1 1,1
 identifiera l’entité, et est souligné tout en en haut. TRIP

 • Identifier les relations entre les entités et les nommer par title
 description
 un verbe. CONCERN start_date PROPOSED FOR
 • Définir les cardinalités : les quantités minimum et maximum 1,N
 end_date
 location
 0,N

 qui peuvent exister entre deux entités A et B. user_id
 password
 picture

 Cas de notre MCD pour la relation utilisateur-voyage 0,N

 SUGGESTED FOR

 Combien de voyages peut créer un utilisateur au minimum ?
 => 0 (si l’utilisateur n’a pas terminé un seul voyage).
 Combien de voyages peut créer un utilisateur au maximum ? Représentation graphique du MCD réalisé sur Mocodo Online
 => n (plusieurs). (mocodo.wingi.net)
 Par combien d’utilisateurs un voyage peut-il être créé au minimum ?
 => 1 (il faut au moins un utilisateur pour écrire un voyage).
 Par combien d’utilisateurs un voyage peut-il être créé au maximum ?
 => 1 (pas de co-utilisateurs).

16

Mise en place de l’application :
Dictionnaire de données

À partir du Modèle Logique de Données/MLD, nous pouvons rédiger un dictionnaire de données listant l’ensemble des
tables, des champs qui les composent, et des relations qui les lient.
Tout d’abord, nous listons chacune des tables présentes dans le MLD.
Ensuite, pour chaque table, nous listons chaque information / champ qui la compose.
Puis, pour chaque champ, nous allons :
- Indiquer son type (nombre, texte, booléen, calculé à partir d’autres informations...)
- Définir ses spécificités ou contraintes (clé primaire, auto-incrémentée, unique, non nulle...)
- Ajouter une description
- Ajouter un commentaire si besoin
Pour les types et spécificités des champs, nous avons décidé dans notre exemple de nous baser sur le Système de
Gestion de Bases de Données Relationnelles MySQL.
Enfin, nous rapportons les relations entre les tables :
Pour les relations dont les cardinalités sont (0,1) (1,1)
(0,n) (1,n), il faut définir quelle table contient la clé
étrangère faisant la liaison entre les deux tables ;
Pour les relations dont les cardinalités sont de type
(n,n), il faut créer une table d’association entre les
deux tables.
La bonne pratique étant de le rédiger en anglais car
ces données serviront à la création de la base de
données (qui devra être en anglais).

 17

Mise en place de l’application :
 MLD/Modèle Logique - MPD/Modèle Physique

 Le modèle logique est une étape vers le modèle physique final. Le MLD découle directement du MCD, en appliquant
 quelques règles - toute la réflexion a été faite au niveau du MCD. Pour se faire :
 • toute entité du MCD devient une table du MLD. Les propriétés de ces entités deviennent les colonnes des tables.
 L’identifiant de l’entité devient la clé primaire de la table.
 • Si l’une des cardinalités max. vaut 1, une clé étrangère est créée du côté de l’entité où se trouve le 1. Cette clé étran-
 gère fera référence à l’identifiant dans la table associée. Exemple (Voyage est créé par 1 utilisateur), c’est donc le
 Voyage qui aura une clé étrangère vers l’Utilisateur.
 • Si les deux cardinalités max. sont n, donc une relation «plusieurs à plusieurs» la relation devient une table à part
 entière en relation avec les deux entités. Cette table de liaison contient 2 clés étrangères vers les 2 tables à lier.
 Le modèle physique est l’implémentation directe du MLD. Après quelques ajustements de nommage et la définition
 des types de champs issue du dictionnaire de données, on obtient ce schéma dans MySQL :

  doctrine_migration_versions 
  user  version VARCHAR(191) NN
 id INT(11) NN executed_at DATETIME
 email VARCHAR(180) NN execution_time INT(11)
 roles LONGTEXT NN
 password VARCHAR(255) NN
 lastname VARCHAR(128) NN
 rstname VARCHAR(128) NN
 avatar VARCHAR(128)
 
 

 
 

  trip 
  activity 
 id INT(11) NN
 id INT(11) NN
 creator_id INT(11) NN
  disponibility  creator_id INT(11)
 
 
 
 

 
 

 title VARCHAR(64) NN
 
 

 id INT(11) NN category_id INT(11) NN
 
 

 description LONGTEXT
 trip_id INT(11) NN trip_id INT(11) NN
 start_date DATE
 start_date DATE title VARCHAR(64) NN
 end_date DATE
 end_date DATE description LONGTEXT
 location VARCHAR(255)
 start_date DATE
 image VARCHAR(128)
 end_date DATE
 
 

 password VARCHAR(64)
 
 

 
 

  suggestion 
 id INT(11) NN
  user_trip  user_id INT(11)  user_disponibility 
 
 

 user_id INT(11) NN trip_id INT(11) NN user_id INT(11) NN
 trip_id INT(11) NN title VARCHAR(64) NN disponibility_id INT(11) NN
 description LONGTEXT NN
 created_at DATETIME NN

 Schéma de la BDD représenté à l’aide
 de Moon Modeler de Datensen
  category 
 id INT(11) NN
 name VARCHAR(64) NN
 image VARCHAR(128) NN

18

Mise en place de l’application :
Wireframes
 Desktop

Après réalisation de l’arborescence du site, il a été possible de commencer à
penser à la conception même du site à l’aide de wireframe (maquette fonction-
nelle). Le wireframe est un schéma utilisé pour définir le zoning (découpage)
des composants d’une interface utilisateur.
Nous avons discuté en équipe via Discord de l’aspect général du site voulu et
j’ai pu réaliser une esquisse en live via partage d’écran sur Adobe XD dispo-
nible à l’adresse suivante :
https://xd.adobe.com/view/7e87fb43-49e5-4f82-8a9c-311d64abc0d4-2bd4/
Après quoi, chaque participant du projet a dû en réaliser plusieurs wireframes
d’une page distincte. Nous avons utilisé l’outil web WireframePro (mockflow.
com) afin de partir sur la même base et obtenir des wireframes au rendu similaire.
J’ai eu à ma charge la conception de la page d’un voyage en version desktop Mobile

et son adaptation mobile.
Ces maquettes en fil de fer servent à définir le zoning de chaque élément de
la page de manière simplifiée et compréhensible par tous (la charte graphique
étant définie ultérieurement). On retrouve ici l’aspect même de la page et une
légende des éléments présents.
La représentation des éléments se fait ici via :
• un trait large pour un titre
• un trait fin pour du texte
• un rectangle barré pour un élément graphique
• Un rectangle vide pour un bouton
 De haut en bas : miniatures page Voyage version desktop, version
• Texte et flèche pour détails de l’élément
 mobile. Voir annexe.
 19

Mise en place de l’application :
 Charte graphique

 De par mon background graphique, je me suis proposé à faire des recherches
 sur l’aspect même de l’application, de son interface, aux couleurs et les
 typographies utilisées en passant par un logo afin de mieux représenter
 O’Vacances.
 Le logo a été réalisé par mes soins sous Adobe Illustrator. C’est un clin d’oeil
 à celui d’O’Clock. Il représente l’unité, la sérénité, et le voyage. La nuance de
 bleu vert représente le calme et la paix et c’est une couleur que l’on retrouve
 aussi bien dans les océans que dans les glaciers.
 L’utilisation de 2 polices, une pour les titres, l’autre pour les textes, apporte
 du contraste ainsi que des formes compatibles pour obtenir une lecture
 plus agréable.
 Recherches (titre, texte) : Poppins / Lato. Cabin / Open Sans. Quicksand /
 Nunito.
 Nous avons retenu le combo Quicksand pour les titres et Nunito pour les
 textes:
 - Quicksand apporte de la légèreté de par ses formes arrondies
 - Nunito donne un look professionnel tout en étant décontracté
 En termes de couleurs nous avons opté pour un thème sobre et épuré. La
 couleur principale est le blanc avec des teintes de noir et l’ utilisation du
 vert (PANTONE 14-5711 TPX Ocean Wave / • #8EC5B7) pour les boutons.
 Concernant l’interface même du site, je me suis inspiré de AirBnb qui offre
 un look soigné sur thème clair et une découpe propre des éléments offrant De haut en bas : logo O’Vacances, palette de couleurs, typographies

 un accès rapide et efficace des informations et leur accès. utilisées

20

Roadmap

Notre product roadmap s’est défini selon les 5 sprints prévus lors de la réalisation du projet.
Elle permet de partager la vision commune des enjeux du projet, mais également d’avoir un suivi direct sur son avancée
tout en donnant de la visibilité aux personnes en ayant besoin et permettre la priorisation des étapes face aux valeurs
de l’équipe.

Roadmap d’Ovacances

 21

IV. SPÉCIFICATIONS TECHNIQUES

22

Versioning

Le versioning d’O’Vacances a été réalisé à l’aide de l’outil Git, l’outil open-source le plus utilisé permettant de gérer
différents projets (appelé repo) en les envoyant sur un serveur. Ce dernier est connecté à l’ordinateur d’autres déve-
loppeurs qui envoient leur code et récupèrent le vôtre. Toute personne qui travaille sur un projet est connectée avec
les autres, tout est synchronisé.
Quant à Github, il s’agit d’un logiciel, ou plateforme. Leur rôle est d’héberger ces différents projets qui utilisent Git.
Concrètement, ils proposent une interface graphique qui vous en simplifie l’utilisation.
Pourquoi utiliser Git ?
• L’aspect backup régulier du code, le versioning, est essentiel dans le développement web. Une panne de disque
 dur pourrait être fatale.
• L’aspect collaboratif qu’offre Git devient rapidement essentiel lorsqu’il y a plus d’un développeur dans le projet.
• Il permet de garder une trace des versions antérieures du site. Très utile en cas de debug.

Versioning projet et workflow
Nous avons choisi d’héberger la partie client et la partie serveur de notre application au sein d’un même repo dans leur
dossier respectif.
Afin d’éviter tous conflits et séparer les concepts, une branche front et une branche back on été créées depuis la branche
principale (master). Chaque équipe se positionne sur sa branche directive, et nous avons créé une nouvelle branche au
titre explicite (ex. depuis le terminal : git checkout -b front-newFeature) à chaque ajout de fonctionnalité (= User Story,
représenté par un ticket sur Trello).
Une fois la fonctionnalité finie on effectue une PR (Pull Request) de sa branche vers la branche directive (front/back). Les
autres membres de l’équipe concernée sont chargées de code review afin d’éviter des erreurs ou rectifier le code. Une
fois la PR validée, et s’il n’y a pas de conflit avec la branche de destination on merge la PR : le contenu de la branche
de fonctionnalité est intégré à celle de destination.
Une fois assez de fonctionnalités ou en fin de sprint, on effectue une PR vers la branche master. 23

Technologies du front-end

 La partie front-end de notre application à été réalisée avec React, framework développé Facebook utilisant Javascript
 et un DOM virtuel bien plus rapide que le DOM original, la possibilité de réutiliser les composants de React permet
 de gagner du temps, le flux de données unidirectionel fournit un code stable, de plus la librairie est open-source ce
 qui facilite la recherche d’informations et de résolution de problème.
 La centralisation des données s’est faite à l’aide de Redux qui permet de par son flow unidirectionnel une gestion de
 state (stockage locale de données dans nos composants) de manière global et accessible par tous les composants.
 React permettant de faire ce que l’on appela une SPA (Single Page Application), nous avons utilisé React Router afin
 d’avoir des routes virtuelles (seuls les composants présents sur la route sont placés dans le DOM virtuel, le résultat
 est direct. L’utilisateur n’a pas l’impression d’avoir subi un chargement de page). Ces routes nous permettent d’accéder
 aux pages de voyage, activités, profil, contact...
 La gestion des formulaires a été initialement faite via des champs contrôlés et les données stockées dans Redux.
 Par manque de connaissances et de temps, je n’ai pu intégrer React Hook Form qu’après la fin de projet. RHF permet
 une gestion externe des champs de saisie offrant de meilleures performances qu’avec Redux (moins de rendues des
 composants, validation des champs, création d’un composant réutilisable...).
 La communication vers les données de l’API était initialement faite via un middleware dans Redux utilisant des
 actions de ce dernier ainsi que la librairie Axios pour effectuer les requêtes HTTP, les résultats passants ensuite
 dans le flo de Redux avant d’être enfin stocké dans Redux même. J’ai pris la peine en fin de projet de passer pars RTK
 Query, qui similaire à React Query, permet de séparer la logique et les problèmes liés à l’utilisation d’une API
 (données partagées et modifiables par différentes personnes, nécessitant d’être rafraichie, ou encore pas de cache et
 d’invalidation pour optimiser les requêtes). On peut ainsi également séparer dans notre application le fonctionne-
 ment propre à l’application et celui de l’API.
 Concernant la partie graphique, notre choix initial était l’utilisation de la librairie de composants Semantic UI, que nous
 avons pu utiliser au sein de notre formation et qui auraient apporté un gain de temps considérable. Néanmoins par
 manque de customisation et de notre jeune expérience afin de palier à ce problème, après discussion avec l’équipe le
 choix s’est fait de partir sur un thème from-scratch utilisant le préprocesseur SCSS pour une liberté et un contrôle absolu.
24

Technologies du back-end

La partie back-end a été réalisée à l’aide du framework PHP Symfony dont l’approche se base sur des composants et
et du modèle MVC (Model-View-Controller). Toutefois son utilisation dans ce projet a été en mode API REST avec et
Model-Controller uniquement, la vue étant gérée directement via React.
MakerBundle a été utilisé pour permettre de générer rapidement des commandes vides, contrôleurs, classes de
formulaire, etc. en une ligne de commande.
L’ORM Doctrine a été utilisé pour la gestion de base de données, en tant qu’ORM son rôle est de transformer les
objets PHP en écriture SQL, et récupérer les écritures SQL et les transformer en objet PHP. L’utilisation de Doctrine
apporte une couche d’abstraction qui nous permet de nous focaliser sur la gestion de la logique métier de notre appli-
cation. L’ORM Doctrine est suffisamment générique pour nous permettre d’utiliser à partir d’une même configuration
aussi bien une base de données MySQL, PostgreSQL ou autres. De plus, pour la sécurité de notre application, Doctrine
apporte nativement un ensemble de bonnes pratiques qui permettent entre autres d’éviter toutes les failles de type
injection SQL avec peu d’efforts de notre part.
Les annotations servent à apporter de l’information à un script. Par exemple les annotations Doctrine permettent de
définir le type de colonne qu’il faut créer dans la table pour correspondre à un attribut de classe. Doctrine vient lire
l’information contenue dans l’annotation, et agit en conséquence.
Le bundle Lexik JWT Authentication pour l’utilisation de token JWT, ce jeton sera envoyé envoyer à chaque requête
que l’on souhaite effectuer auprès d’une API afin de s’authentifier. Il contient toutes les informations nécessaires à
notre identification.
L’utilisation de Mailer est prévue pour le mailing implanté à l’application (invitation automatique à la création d’un
voyage, formulaire de contact, mot de passe oublié)
Notre serveur Symfony est lié à une base de données MySQL, administré via le gestionnaire de base de données
Adminer ou PHPMyAdmin selon les goûts de chacun.

 25

Sécurité de l’application

 La sécurité de l’application peut être scindée en deux parties:
 Client
 Il est nécessaire de s’authentifier en tant que membre pour avoir accès à des opérations sur la base de données.
 Le token JWT est stocké dans le locale Storage (facile d’accès, il peut néanmoins être accessible par d’autres sites
 cherchant dans ce stockage, ou pire être intercepté, offrant au pirate le contrôle total du compte de la victime. Plus de
 détails sur le choix cookies de session vs JWT Token dans les pages suivantes), celui-ci est ajouté à chaque requête
 faîte par l’utilisateur vers l’API.
 - On cache dans notre interface utilisateur toute commande inopérable par un utilisateur (ex. : supprimer/modifier un
 voyage, une activité ou une suggestion dont on n’est pas l’auteur), offrant déjà une première sécurité sur des actions
 non intentionnelles ou malveillantes.
 - Au clic sur une action déclenchant un appel vers l’API, le token JWT est passé dans le header de la requête HTTP.
 Si celui-ci est valide, l’opération continuera et nous traiterons les données de réponse côté client. Le cas échéant, un
 message avertira l’utilisateur sur l’erreur même afin de l’aider à comprendre le refus/l’erreur dans la requête.
 Serveur
 - En production, seules les requêtes provenant du serveur front sont autorisées dans les CORS.
 - L’appel à l’API ne peut se faire qu’après une authentification réussie, générant un token propre à l’utilisateur
 connecté.
 - Pour chaque requête effectuée vers l’API, on vérifie la présence du token JWT et sa correspondance avec celui émis
 par l’application au moment de l’authentification. Si le token ne correspond pas ou est expiré, la requête ne pourra être
 effectuée et on enverra une erreur en réponse.
 - Dans chaque action demandée suite à la requête vers l’API et si le token est valide, on prend soin de vérifier dans la
 méthode liée à l’action si l’ID représentant le demandeur de la requête correspond bien, et si ces droits sont suffisants
 pour effectuer l’action demandée.
26

V. ORGANISATION DE L’ÉQUIPE

 27

Présentation de l’équipe

 L’équipe O’Vacances est composée de 5 personnes, la composition de l’équipe a été tirée au sort tout en respectant
 d’avoir le nombre de développeurs spécialisé (ici 2 React/3 Symfony) requis pour le projet.

 Front

 Quentin Cécilia

 Back

 Audrey Alexandre Loïc

28

Répartition et détails des rôles

L’attribution des rôles dans l’équipe s’est faite après concertation entre toute l’équipe, pour évoquer celui ou ceux qu’on
aimerait avoir, mais également parler de nos points forts et points faibles afin de balancer ces choix. On retrouve ainsi
au poste de Lead les personnes ayant la meilleure compréhension de leur technologie et qui en profitera pour le réfé-
rentiel, le Product Owner est l’auteur du projet même. Les postes de Scrum Master et Git Master selon l’expérience et
le l’approche des personnes concernées.
Répartition des rôles
Quentin
• Lead Dev Front, supervise la partie front du développement ainsi que les choix techniques si nécessaire
• Référent React, documentation de la technologie référente (React)
Cécilia
• Scrum Master, supervise l’avancement global du projet et des tâches effectuées, gestion du Trello avec les stories
• Front Dev
Audrey (auteur du projet)
• Product Owner, donne son avis sur la priorité des tâches lors des sprints plannings et s’assure de la cohérence du
 projet
• Back Dev
Loïc
• Lead Dev Back, supervise la partie back du développement ainsi que les choix techniques si nécessaire
• Back Dev
Alexandre
• Git Master, maître de l’outil Git, aide ceux en difficulté avec Git. Il est le seul développeur autorisé à toucher à la
 branche master
• Back Dev

 29

Organisation de travail

 Organisation et tâches
 Après validation de tous nos documents de projet en fin de sprint 0 et au début du sprint suivant, nous
 avons représenté chaque User Stories dans un tableau Trello sous forme de tickets, labellisées selon
 si front/back et le composant associé.
 Suivi de la planification, selon le fil d’Ariane du projet afin d’avancer dans un ordre logique et définir
 les tâches principales.
 Grâce au planning poker on estime à l’aide de chiffre la complexité et la taille d’un ticket. Lors du
 sprint, chacun effectue un à un les tickets du sprint sans oublier de les déplacer dans la case suivante
 une fois effectuée.
 Cette organisation nous a permis un suivi précis de l’avancement du projet, mais également de voir le
 succès des engagements du sprint. Si un ticket a pris plus de temps que prévu, en plus d’avoir décrit le
 problème à l’oral lors du daily, il y avait aussi une trace écrite partiellement sur Slack, et le suivi complet
 dans le journal de bord rédigé régulièrement de la personne qui a effectué le ticket.
 En plus de la roadmap, le fichier dictionnaire des routes a été copié et mis à jour régulièrement pour
 suivre l’avancée des endpoints via un code couleur : vert: OK, rouge : problème + commentaire.
 Meeting
 Pendant toute la durée du projet nous avons travaillé en horaires 9h-15h + 2 heures de travail sans Extrait des tickets du Trello lors du 1er sprint
 horaire fixe, imposées par l’Apothéose.
 Nous commencions la journée par un daily meeting virtuel via l’application Discord d’une durée de 15mn afin de faire un
 tour de table virtuel de chaque développeur. Chacun évoque le travail effectué la veille, le travail prévu pour la journée,
 mais également et surtout les difficultés rencontrées afin de les résoudre aux plus soit via les connaissances partagées
 lors du daily, ou via un appel (audio et/ou partage d’écran) avec les personnes les plus à même d’aider. Ce daily meeting
 était ensuite séparé entres équipe front/back pour plus de détails sur les tâches en cours.
 Le daily meeting était également l’occasion de faire le point sur les branches et pull requests disponibles et en attente
30 de merge.

Outils utilisés

Communication
• Slack, utilisé tout au long de notre formation et où nous étions connecté en permanence facilitant nos échanges.
 Utiles pour conserver une trace de nos conversations, nous avions un groupe privé incluant nos consultants de projet.
• Discord, logiciel de VoIP et messagerie instantanée. Le serveur d’O’Clock et ses nombreux salons nous ont permis
 de pouvoir échanger vocalement, mais également de faire du partage d’écran.
Documentation
• Google Drive/Docs/Sheets, avec un dossier privé contenant l’équipe et consultant de projet. Principale utilisation de
 Docs et Sheets dans pour la prise de note aussi bien la documentation du projet (cahier des charges, routes, MVC,
 annexes...), les journaux de bord et tous nos travaux de recherches. La possibilité d’avoir plusieurs personnes en
 simultanée pour la lecture et écriture d’un document était également utile lors de prise de notes.
Gestion de projet
• Trello, qui nous a permis de gérer toutes nos User Stories, en planifiant et ayant un suivi de chacune ainsi que du
 travail de toute l’équipe.
Versioning
• Git, l’outil de versioning open-source par excellence. Utilisé tout au long de notre formation. Nous avons également
 mis en place un document servant de guide pour effectuer des commits structuré et compréhensible de tous.
• GitHub, pour le partage de code et publication du projet.
Développement
• VS Code, éditeur de code open-source. Très complet, utile tout au long de notre formation et customisable à l’aide
 de ses nombreuses extensions gratuites communautaires pour augmenter sa productivité.
• Insomnia, utilitaire pour tester les endpoints d’une API.
Hébergement
• Deux serveurs AWS EC2 pour déploiement front/back distinct. Postapothéose (après épuisement des crédits AWS),
 l’hébergement front est effectué via la plateforme Vercel qui offre un hébergement gratuit d’application Node, tandis
 que le back est hébergé dans un environnement dockerisé sur mon serveur AWS EC2 personnel.
 31

Programme des sprints

 Nous avons travaillé en sprint grâce à la méthode AGILE SCRUM. Chaque sprint a eu une durée d’une semaine, nous
 avions régulièrement (1 fois par semaine généralement), une réunion avec les consultants afin de faire un point sur
 l’avancement du projet, les sujets bloquants et de répondre à toutes les questions rassemblées au cours de la semaine.
 Au début d’un nouveau sprint, une présentation par équipe avec une personne désignée été effectuer devant l’ensemble
 de la promotion afin de s’entraîner pour la présentation en live de fin.
 Sprint 0
 Le premier sprint a été consacré à l’élaboration du cahier des charges, des différents documents (MVC, arborescence
 du site, routes, schéma BDD, wireframes...) mais aussi la définition des rôles de chacun.
 Ce sprint s’est déroulé sans accroc, nous avons pu valider la majorité des documents lors du premier meeting de vali-
 dation avec notre consultant de projet. Seule correction à effectuer : notre MCD, car nous avions inversé les cardinalités.
 Suite à quoi au deuxième meeting validation du MCD et nous avons eu le feu vert pour commencer à coder.
 Sprint 1
 Il marque le début du code ! Ce fut le moment de réévaluer les enjeux du projet et modifier le cahier des charges si
 nécessaires. C’est le moment où l’utilisation de Trello a vraiment montré son potentiel via la disposition des cartes et
 l’ajout de détails pour certaines stories.
 Côté front : création du dossier de projet React dans le repo, installation des modules requis. Répartition de l’intégration
 statique avec Cécilia pour toutes les pages, et on prépare la dynamisation avec de fausses données.
 Côté back : création du dossier de projet Symfoy et installation des bundles requis. On met en place la gestion de l’au-
 thentification et du token JWT tout en avançant sur l’API. Mise en place de la BDD, des entités, fixtures, CORS et token
 JW tout en avançant sur les routes (utilisateur et voyage principalement).
 Sprint 2
 Toujours plus de code ! On ajoute et améliore les fonctionnalités tout en corrigeant les bugs.

32

Programme des sprints

Côté front : Connexion à l’API réussie ! Dynamisation des pages via les endpoints, corrections des bugs. Déploiement.
intégration page voyage avec fausses données, ajout de l’intégration pour l’ajout d’un voyage et pages manquantes
avec fausses données. Ajout des middlewares trip et user.
Côté back : Avancement sur les endpoints trip et user principalement, on peut désormais recevoir les images uploadées
du front. Déploiement. Avancement sur les endpoints suggestions, activités et disponibilités. Résolution problème CORS
pour communication avec le front en fin de sprint.
Sprint 3
J-3 pour la présentation live sur YouTube de notre application ! Plus question d'ajouter des fonctionnalités. On finit la
fonctionnalité actuelle, vérifie en équipe toutes les fonctionnalités fonctionnelles ou non et améliorations/corrections
rapides des problèmes front/back rencontrés en vue de la présentation.

 33

VI. COMPÉTENCES DU RÉFÉRENTIEL

34

Partie front-end :
CP1 - Maquette une application

Après élaboration des User Stories et selon les goûts de l’équipe pour le thème de l’application, comme vue
précédemment dans « Mise en place de l’application : Wireframes », vint l’élaboration des wireframes défi-
nissant le zoning de notre application.
Ici, pour la réalisation de la page d’accueil visiteur, on se base sur les User Stories de la page d’accueil (voir Slideshow d’images

annexe).
Puis à l’aide de l’application en ligne MockFlow, nous avons créé un nouveau projet pour cette page, et com-
mencer à réaliser le wireframe pour un affichage mobile (car conception d’O’vacances en mobile-first), en
utilisant comme référence dans ce cas un iPhone PLUS 8 (414x736px).
On commence par mettre en place le header avec le logo à gauche et les boutons de connexion à droite offrant
un flo naturel qu’on retrouve sur la majorité des sites web.
Puis un rectangle gris représentant le slideshow avec des images de différents types de voyage qui défileront
et modifiable au clic, avec par-dessus le texte d’accroche du site.
S’en suive la présentation des fonctionnalités ici une à une afin d’optimisé l’affichage-écran, et présentant
 Wirefame Accueil, version mobile
grâce à un screenshot et un bref texte explicatif son utilité.
 Puis le call to action, avec un bouton redirigeant l’utilisateur vers la page d’inscription au clic.
 Un bouton avec une flèche directive vers le haut est placé en bas à droite de l’écran, celle-ci
 permet au clic de l’utilisateur de retourner en haut de page plutôt que de scroller.
 Après la création de la page en version mobile, nous avons pu décliner l’affichage pour un
 écran de PC (1920x1080p), notamment avec le slideshow prenant toute la vue de la fenêtre
 à l’ouverture, avec un bouton pour scroll automatiquement; et dû au gain de place horizontale,
 l’affichage des fonctionnalités avec screenshot et texte au même niveau.

 Wirefame Accueil, version desktop
 35

Partie front-end :
 CP2 - Interface statique et adaptable

 L’application ayant été composée en mobile-first, il a fallu adopter son affichage selon les supports utilisés (télé-
 phone, ordinateur...) afin d’optimiser l’affichage, ceci a été fait grâce à l’utilisation d’unités de mesure relative ainsi que
 des Media Queries dans les feuilles de styles SCSS de l’application qui seront ensuite compilées en CSS. Le choix
 des règles à appliquer repose principalement sur la résolution d’écran, le type d’écran ainsi que son orientation.
 La landing page est un bon exemple, car l’affichage du slideshow et des fonctionnalités dépend du support utilisé.
 Slideshow
 Le slideshow prend l’intégralité (hors layout) de l’affichage-écran, néanmoins il
 a fallu prendre en compte l’orientation différente de l’affichage sur desktop (hori-
 zontale) et mobile (verticale).
 On retrouve dans le code de style SCSS du slideshow un affichage prenant tou-
 jours 90vh (viewport height, hauteur de la fenêtre), et une largeur de 100% de
 l’élément, permettra de couvrir l’affichage complet que l’on soit sur l’un des deux
 supports cités.
 L’image elle est positionnée selon le point haut gauche de son container .slideshow,
 avec encore ici l’utilisation de vh et % pour la taille et la hauteur. Les propriétés l. 18 à 20 du
 screenshot permettent de faire contenir (contain) l’image dans son élément, et grâce à la position
 de background l.20 s’assurer que l’image est toujours centrée pour éviter d’avoir l’un des côtés
 de l’image et donc pas le sujet principal.
 Le contenu (textes) est centré dans le container ‘.slideshow’ grâce aux propriétés l. 28 à 30. On
 retrouve également @media (min-width: $desktop) à différents endroits afin d’optimiser l’affi-
 chage desktop, car disposant d’une résolution plus grande.

 Slideshow en version desktop
 puis mobile

36