2021

RAPPORT
Ric’ard

ROMAIN RICARD
Table des matières
I. Introduction .................................................................................................................................... 4
A. Présentation............................................................................................................................... 4
B. Présentation de l’entreprise et l’environnement informatique ............................................ 4
C. Présentation du projet .......................................................................................................... 4
II. Cadre du projet ............................................................................................................................. 5
A. Enjeux et objectifs..................................................................................................................... 5
B. Livrables ..................................................................................................................................... 5
III. Conception graphique .............................................................................................................. 5
A. Brief créatif ................................................................................................................................. 5
B. Charte graphique ...................................................................................................................... 5
IV. Spécifications fonctionnelles ................................................................................................... 6
A. Périmètre fonctionnel ............................................................................................................... 6
1. Les acteurs ............................................................................................................................ 6
2. Les fonctionnalités ................................................................................................................ 6
B. Arborescence ............................................................................................................................ 7
C. Aperçu des contenus ........................................................................................................... 9
1. Page d’accueil : A propos/Présentation ............................................................................ 9
2. Peintures ................................................................................................................................ 9
3. Catégorie................................................................................................................................ 9
4. Détail produit ......................................................................................................................... 9
5. Tarifs ..................................................................................................................................... 10
6. Expositions........................................................................................................................... 10
7. Contact ................................................................................................................................. 10
8. Authentification.................................................................................................................... 10
9. Gestion des articles ............................................................................................................ 11
10. Gestion des catégories .................................................................................................. 12
11. Gestion des expositions................................................................................................. 13
V. Spécifications techniques .......................................................................................................... 14
A. Choix technologiques ............................................................................................................. 14
1. Langage de programmation .............................................................................................. 14
2. Type de base de données ................................................................................................. 14
3. Localisation des applications et des bases de données............................................... 14
4. Validation des formulaires ................................................................................................. 14
B. Accessibilité ............................................................................................................................. 15
C. Service tiers ......................................................................................................................... 15
Romain Ricard 1
 D. Performances attendues ................................................................................................... 15
E. Sécurité .................................................................................................................................... 16
F. Maintenance et évolutions..................................................................................................... 16
VI. Réalisation et suivi du projet ................................................................................................. 17
A. Informations générales .......................................................................................................... 18
1. Langage ............................................................................................................................... 18
2. Structure de la base de données ..................................................................................... 18
B. Développement des fonctions .............................................................................................. 21
1. Mise en place de la base de données ............................................................................. 21
C. L’authentification ................................................................................................................. 23
D. Gestion des articles ............................................................................................................ 27
1. Liste d’articles ...................................................................................................................... 27
2. Supprimer un article ........................................................................................................... 28
3. Création et modification d’article ...................................................................................... 29
VII. Test et Recettage ................................................................................................................... 33
VIII. Déploiement............................................................................................................................. 34
IX. Les backups............................................................................................................................. 34
X. Conclusion ................................................................................................................................... 34

Romain Ricard 2
 Compétences professionnelles Réalisations

Maquetter une application

Développer des composants d’accès aux données

Développer la partie frontend d’une interface utilisateur web

Développer la partie backend d’une interface utilisateur web

Concevoir une base de données

Mettre en place une base de données

Développer des composants dans le langage d’une base de

données

Collaborer à la gestion d’un projet informatique et à l’organisation de

l’environnement de développement

Concevoir une application

Développer des composants métier

Construire une application organisée en couches

Préparer et exécuter les plans de tests d’une application

Préparer et exécuter le déploiement d’une application

Romain Ricard 3
I. Introduction

A. Présentation

Je m’appelle Romain Ricard, je suis âgé de 29 ans. J’ai découvert l’informatique par
hasard et relativement tard lors d’un voyage au Canada via quelqu’un de ma famille
qui m’a fait connaître ce métier. J’ai trouvé une satisfaction personnelle, réussir à
avoir quelque chose de fonctionnel. J’ai donc poursuivi dans ce sens.

J’ai commencé mon cursus avec un certificat en informatique et développement de

logiciel à Montréal durant 1an puis de retour en France j’ai passé un BTS SIO option
SLAM.

J’ai été durant 2ans au sein de deux entreprises différentes en tant que développeur
PHP en alternance.

Aujourd’hui je cherche à m’améliorer sur ces compétences backend et frontend dans

le but de développer des outils maintenables et sécurisés sur le long terme.

B. Présentation de l’entreprise et l’environnement informatique

L’entreprise est une auto-entreprise gérée par mon père, Michel Ricard et ma mère,
Françoise Ricard. Mon père fait de nombreux marchés et expositions à l’année dans
toute la région vendéenne.
Il propose la vente d’œuvres de peinture réalisé au fer à repasser et à la cire
d’abeille.
Divers formats et types de tableaux sont disponibles. L’intérêt étant de voir le peintre
en action, comme avec un caricaturiste. C’est en le voyant faire ses démonstrations
qu’il permet au public de découvrir et d’apprécier ce style bien particulier.

Pour ce qui est de l’environnement informatique comme il s’agit d’un projet personnel
je suis seul dans mon bureau à Chalonnes sur Loire.

C. Présentation du projet

The project is simple realization of a website in PHP with a Mysql database for
individuals to see the paintings of Michel Ricard. There will of course be a back office
managed by his wife Françoise Ricard.

She will be able to connect via an identification page.

Romain Ricard 4
If the username and password match, she will have access to a dashboard to add,
delete, modify and see the list of paintings, exhibitions and painting categories.

The visitor will only be able to perform one reading action.

The site is not made to sell but to have a rendering of the works of the artist. A bit like
a cartoonist, what leads a person to make a purchase is to see the painter do it. We
will put in place the maximum recommendation and security of the code throughout
the development. I will also make sure to make a site in accordance with web eco-
design so as little external element as possible.

II. Cadre du projet

A. Enjeux et objectifs

L’objectif du projet est de mettre en place un site web en PHP sans framework avec
une base de données pour inviter d’autres gens à découvrir les œuvres de mon père.

B. Livrables

Afin d’atteindre mon objectif, voici la liste des livrables :

Cahier des charges fonctionnel et technique 12 février

Maquettes de l’application 20 mars

Application Version 1 22 juin

Mise en place du site Début juillet

III. Conception graphique

A. Brief créatif

Le graphisme du site doit être épuré, le plus lisible et facile d’utilisation pour
l’administrateur et les visiteurs.

B. Charte graphique

Romain Ricard 5
Palette de couleur tournera autour de couleur sobre blanc, beige et noir pour
l’écriture.
Typographie de contenu : Comic Neue, cursive
Typographie de titre : Permanent Marker, cursive
Design graphique : Responsive Bootstrap

IV. Spécifications fonctionnelles

A. Périmètre fonctionnel

1. Les acteurs

L’application est divisée en deux parties :

• Le front : Une application web accessible sur plusieurs supports puisque
responsive. Elle sera disponible et accessible pour tous les particuliers.

• Back-office : Toujours la même application web avec différentes pages

comme l’accès à l’identification, un menu spécifique pour la gestion des
articles (peintures), catégories de peinture et les expositions. Elle sera
disponible pour l’administrateur du site qui sera Françoise Ricard et moi-
même

Donc pour ce qui est de la gestion des rôles c’est très simple il y en a qu’un :
l’administrateur.

2. Les fonctionnalités

Pour la création du site on passera par plusieurs versions, certaines

fonctionnalités étant plus impératives que d’autres et avec l’estimation de temps que
l’on a.

Romain Ricard 6
 Fonctionnalité Contrainte(s) associée(s)

Visualisation de la page de Pas de contraintes particulières

présentation

Visualisation des tarifs

Visualisation des catégories

Visualisation des expositions

Visualisation de la page de contact

Authentification Si bon identifiant ok sinon renvoie vers la

page de connexion

Gestion des articles Si identifiant ok

Gestion des catégories

Gestion des expositions

B. Arborescence

Arborescence pour les visiteurs :

Figure 1 : parcours visiteurs

Romain Ricard 7
Arborescence pour les administrateurs :

Figure 2 parcours administrateur

Romain Ricard 8
 C. Aperçu des contenus

1. Page d’accueil : A propos/Présentation

Fonctionnement : La page d’accueil pour les visiteurs permet plusieurs choix

possibles dans le menu l’accès aux pages : tarifs, contact, peintures, expositions

Maquette : Annexes - A propos

Résultat attendu : Affichage du logo de l’entreprise en haut de la page avec le

menu. Une grande image qui sera la bannière avec une photo de l’artiste. Un article
qui présente le peintre et un autre qui présente le type de peinture et avec quel outil.

2. Peintures

Fonctionnement : Possibilité de clique soit sur le titre soit sur l’image associée de la
catégorie pour avoir accès à toutes les peintures de cette catégorie

Maquette : Annexes - Peintures

Résultat attendu : un listage des catégories de peintures présent en base de

données disponible avec un image correspondante et un lien vers ses catégories.

3. Catégorie

Fonctionnement : Possibilité de clique soit sur le titre soit sur l’image associée de la
peinture pour avoir au détail de cette peinture

Maquette : Annexes - Catégorie

Résultat attendu : un listage des peintures correspondant à la catégorie

sélectionnée auparavant, l’image des peintures et les titres présents en base de
données disponibles avec un lien vers le détail de la peinture.

4. Détail produit

Fonctionnement : Affichage de la peinture et de ces informations

Maquette : Annexes – Détail produit

Résultat attendu : à gauche une image d’une plus grande taille environ la moitié de
l’écran sans déformation et à droite le titre suivi de sa description, de sa date de
création et de sa ou ses catégories.

Romain Ricard 9
 5. Tarifs

Fonctionnement : Affichage du tableau de tarification

Maquette : Annexes - Tarifs

Résultat attendu : Affichage d’un grand tableau qui indique le prix en fonction des
catégories, du format et des options.

6. Expositions

Fonctionnement : Affichage de la liste des expositions

Maquette : Annexes - Expositions

Résultat attendu : Liste des expositions sous forme de liste de grande taille, il y
aura l’affichage des expositions qui arrive bientôt avec un badge qui indique si
l’exposition est dans 2 jours ou moins. Si l’exposition est passée, pas d’affichage.

7. Contact

Fonctionnement : Affichage des informations de contact, possibilité en cliquant sur

la carte de faire un itinéraire jusqu’à ce lieu ou d’agrandir le plan.

Maquette : Annexes - Contact

Résultat attendu : Une grande carte avec google map du plan où se situe l’artiste
ainsi que son mail, son adresse et son numéro de portable.

8. Authentification

Fonctionnement : Formulaire d’authentification avec possibilité d’y mettre son nom

d’utilisateur et son mot de passe puis de cliquer sur le bouton de connexion pour
accèder au tableau de bord d’administrateur.

Maquette : Annexes - Authentification

Résultat attendu : Formulaire avec le nom d’utilisateur et le mot de passe ainsi

qu’un bouton de connexion. Si connexion ok alors renvoie vers la page d’admin. Si
non, message d’erreur qui nous indique que l’identifiant ou le mot de passe n’est pas
bon.

Romain Ricard 10
 9. Gestion des articles
a) Liste des articles

Fonctionnement : Affichage de la liste des articles possibilité d’avoir accès à

diverses actions comme la création, modification, suppression d’un article. Le clique
directement sur le titre permet d’éditer le produit.

Maquette : Annexes – Admin articles

Résultat attendu : Affichage des articles avec son id, son titre et les actions que
sont la création, la modification et la suppression.

b) Création/Modification d’un article

Fonctionnement : L’écran de création d’un article est un formulaire avec divers

champs à compléter comme le titre de l’œuvre, son URL, son image, sa ou ses
catégories, son contenu, et la date de création qui sera déjà pré rempli. Un bouton
de création qui permet l’enregistrement en base de données.
L’écran de modification d’un article est un formulaire similaire à celui de création
hormis le fait que les champs sont déjà pré remplis ce qui permet ainsi en cas
d’erreur de l’utilisateur de pouvoir modifier les champs sans avoir à tout refaire. On
aura aussi un aperçu de l’image. Et il s’agit d’un bouton de modification.

Maquette : Annexes – Admin articles création et Admin articles modification

Résultat attendu : Pour l’écran de création/modification d’un article la validation des

champs devra correspondre avec ce qu’on a en base et dans nos validateurs. Un
message sera attendu si les champs sont vides ou ne correspondent pas (exemple :
titre ou slug qui existe déjà). Pour l’image un remplacement sera possible.

c) Suppression d’un article

Fonctionnement : Clique sur le bouton de suppression un message de confirmation

est demander à l’utilisateur. Puis un message une fois la suppression faite.

Résultat attendu : Suppression en base de données de l’article et de l’image dans

le fichier associé.

Romain Ricard 11
 10. Gestion des catégories
a) Liste des catégories

Fonctionnement : Affichage de la liste des catégories possibilité d’avoir accès à

diverses actions comme la création, modification, suppression d’un article. Le clique
directement sur le titre permet d’éditer la catégorie.

Maquette : Annexes - Admin catégories

Résultat attendu : Affichage des catégories avec son id, son titre, son url ainsi que
les actions de création, modification, suppression.

b) Création/Modification d’une catégorie

Fonctionnement : L’écran de création d’un article est un formulaire avec divers

champs à compléter comme le titre, son URL et son image. Un bouton de création.
L’écran de modification d’une catégorie est un formulaire similaire à celui de création
hormis le fait que les champs sont déjà pré remplis ce qui permet ainsi en cas
d’erreur de l’utilisateur de pouvoir modifier les champs sans avoir à tout refaire, on
aura aussi un aperçu de l’image. Et il s’agit d’un bouton de modification.

Maquette : Annexes – Sensiblement le même formulaire que celui d’article

Résultat attendu : Pour l’écran de création/modification d’une catégorie la validation

des champs devra correspondre avec ce qu’on a en base et dans nos validateurs.
Un message sera attendu si les champs sont vides ou ne correspondent pas
(exemple : titre ou slug qui existe déjà). Pour l’image un remplacement sera possible.

a) Suppression d’une catégorie

Fonctionnement : Clique sur le bouton de suppression un message de confirmation

est demander à l’utilisateur. Puis un message une fois la suppression faites.

Résultat attendu : Suppression en base de données de la catégorie.

Romain Ricard 12
 11. Gestion des expositions
a) Liste des expositions

Fonctionnement : Affichage de la liste des expositions possibilité d’avoir accès à

diverses actions comme la création, modification, suppression d’un article. Le clique
directement sur le titre permet d’éditer l’exposition.

Maquette : Annexes – Admin expositions.

Résultat attendu : Affichage des expositions avec son id, sa localisation et sa date
et heure de début ainsi que les actions que sont la création, modification,
suppression.
Le formatage de la date sera en français. Un badge indiquera quand est ce que
l’exposition est fini.

b) Création/Modification d’une exposition

Fonctionnement : L’écran de création d’une exposition est un formulaire avec 2

champs à compléter comme le lieu et sa date et son heure. Un bouton de création
qui permet l’enregistrement en base de données.
L’écran de modification d’un article est un formulaire similaire à celui de création
hormis le fait que le champs titre est déjà pré remplis. Et il s’agit d’un bouton de
modification.

Maquette : Annexes – Sensiblement le même formulaire que celui d’article

Résultat attendu : Pour l’écran de création/modification d’une exposition la

validation des champs devra correspondre avec ce qu’on a en base et dans nos
validateurs. Un message sera attendu si les champs sont vides ou ne correspondent
pas (exemple : titre existe déjà).

c) Suppression d’une exposition

Fonctionnement : Clique sur le bouton de suppression un message de confirmation

est demander à l’utilisateur. Puis un message une fois la suppression faites.

Résultat attendu : Suppression en base de données de l’exposition.

Romain Ricard 13
V. Spécifications techniques

A. Choix technologiques
1. Langage de programmation

Besoins Contraintes Solutions

Facilité de maintien • Techniques Il conviendra donc

pour le futur avec • Temps d’utiliser une solution
une grande • Budgets de type PHP.
communauté
réactive.
Un langage déjà
connu

Je fais le choix de ne pas utiliser de Framework malgré des bases en connaissance

Symfony 5 car je souhaite apprendre les bonnes pratiques ainsi que les critères de
sécurisation d’un site sans passer par un outil qui réalise une partie du travail. La
version utilisée sera PHP 7.2 avec un modèle en couche de type MVC. Pour la partie
design je passe par du boostrap pour son côté responsive rapide et efficace.

2. Type de base de données

Le type de base de données utilisé par l’application est MySQL. Le système étant
une application Web la communication entre eux est simple et l’outil est gratuit. Je ne
passe pas par une ORM écriture de la base de données en langage sql. Je passe
néanmoins par une interface phpmyadmin.

3. Localisation des applications et des bases de données

La base de données et notre application vont être hébergé chez OVH hébergeur
français.

4. Validation des formulaires

La validation est une tâche très courante dans les applications Web. Les données
saisies dans les formulaires doivent être validées. Les données doivent également
être validées avant d'être écrites dans une base de données ou transmises à un
service Web.

Je passe par une librairie Validator acquis sur packagist qui me facilite la tâche.
On pourra ainsi gérer différentes contraintes comme :

Romain Ricard 14
 • Des contraintes de base par exemple les types savoir si le champ doit être nul
ou vide.
• Des contraintes de chaînes pour les champs spécifiques comme les mots de
passe ou les e-mails, la longueur attendue dans ses champs.
• Des contraintes de date pour avoir un datetime adapté dans notre cas.
• Des contraintes de choix utilisées pour les listes déroulantes.

B. Accessibilité

Le site sera compatible avec les navigateurs suivants :

• Google Chrome
• Mozilla Firefox
• Microsoft Edge
• Opera

L’application sera conçue en responsive avec le Framework frontend Bootstrap

version 5.0 afin d’assurer une navigation optimale sur tous types d’appareils :
• Tablettes
• Ordinateurs portables
• Ordinateurs de bureau
• Mobiles

Mise en place des recommandations du référentiel général d’amélioration de

l’accessibilité.

C. Service tiers

Solution de versionning : Github en privé. Ceci permettant de maintenir le projet avec

une visibilité réduite dessus et d’avoir un back-up en cas de problème.
Solution d’IDE : Visual studio code avec quelques extensions.
Mise en place de diverses librairies que j’ai récupéré sur packagist, ainsi qu’un suivi
du site avec google analytics.

D. Performances attendues

L’affichage doit pouvoir s’afficher rapidement en moins de 2 secondes.

Romain Ricard 15
 E. Sécurité

L’accès aux comptes d’administration sera limité à 2 personnes :

• Françoise Ricard
• Romain Ricard
Pour tout ce qui touche à la sécurité j’ai pris des informations sur la doc de l’ANSSI
concernant la sécurisation des sites web. Ainsi que sur les normes OWASP.
Pour éviter les injections sql je passe par des requêtes préparées.
Pour éviter les failles XSS je fais en sorte d’utiliser la fonction htmlentities qui
convertit tous les caractères éligibles en entités HTML pour éviter que des
informations malicieuses soient enregistrées dans la base de données ou celle qui
sont tirées de la base de données pour son affichage.

Pour la sécurité autour de la session je passe par un bouton déconnexion qui détruit
la session en cours pour l’administrateur.
Concernant la protection des données en transit je passe par un certificat ssl et dans
mon htaccess il y a une redirection de tous les liens http vers https. J’utilise des
méthodes post pour la modification et transmission de donnée et get pour la
récupération d’informations. Grâce à ce certificat je m’assure que le corps est chiffré.
Donc protection CORS (cross origin resource).
La base de données ovh est accessible seulement via un utilisateur qui a un nom et
un mot de passe, moi-même. De plus dans ma table user je hash le mot de passe en
bcrypt.
J’empêche l’exploitation des contrôles d’accès grâce à des routes spécifiques qui ne
sont accessibles que si on a une session d’admin valide donc que l’on s’est
connecter auparavant sur le site avec les bons identifiants.

F. Maintenance et évolutions

La maintenance évolutive sera effectuée par moi-même.

Une amélioration du référencement sera faite, ainsi que des modifications
concernant le design.

Romain Ricard 16
VI. Réalisation et suivi du projet
Dans la partie qui suit, nous allons nous attarder sur le développement des
fonctionnalités de l’application. Nous allons rentrer en détail sur le fonctionnement et
sur la méthode de développement mise en place.

Figure 3 Cas d'utilisation

Romain Ricard 17
 A. Informations générales
1. Langage

Pour développer l’application, j’ai utilisé le langage PHP version 7.2 sans Framework
afin de structurer le développement j’ai créé des dossiers qui m’ont permis de
constituer mon modèle en couche.
Dans un premier temps mon application sera développée sur wamp qui sera mon
environnement de test avant le déploiement.
L’application va être structurée en différentes couches ayant chacune un objectif
différent :

• Public : contient le css, les images du site et à la

racine mon index.php où sont définis toutes les routes de
mon application.
• Model : C’est ici que se trouve les objets avec leurs
attributs et leurs assesseurs.
• Table : Il fait les liens entre les différentes couches
de l’application. C’est là que sont créées les méthodes
qui permettent les créations, modifications etc.
• HTML : Permet la construction de formulaires avec
le dossier form.php
• Repository : Permet l’accès aux données sur tout
ce qui est affichage.
• Validator : Pour la gestion du formulaire
d’identification.
• Views : Il y a toutes les vues de mon site.

Figure 4 Arborescence du site

2. Structure de la base de données

La base de données c’est du Mysql, on passera par une interface phpmyadmin.

Elle est créée avec du langage sql dans un fichier .sql que j’importe par la suite sur
phpmyadmin.

Mais avant cela on va concevoir ce à quoi va ressembler notre base de données on

passe.

Romain Ricard 18
Figure 5: Modèle logique

Post correspond à nos peintures.

Category correspond à nos catégories de peinture.

Exhibition correspond à nos expositions.

User correspond à nos utilisateurs donc nos admin notre champ password sera
haché.

Il y a 5 entités :
• Category
o Id :
▪ Clé primaire
▪ Auto-implement
▪ Type : integer.

o Name :
▪ Unique
▪ Type : varchar (255)
▪ Null : non

o Slug
▪ Unique
▪ Type : varchar (255)
▪ Null : non

o Image

Romain Ricard 19
 ▪ Unique
▪ Type : varchar (255)
▪ Null : oui

• Post
o Id :
▪ Clé primaire
▪ Auto-implement
▪ Type : integer.

o Name :
▪ Unique
▪ Type : varchar (255)
▪ Null : non

o Slug :
▪
Unique
▪
Type : varchar (255)
▪
Null : non
o Image :
▪ Unique
▪ Type : varchar (255)
▪ Null : oui

o Created_at :
▪ Type : datetime
▪ Null : non

o Content :
▪ Type : text
▪ Null : oui

• Exhibition
o Id :
▪ Clé primaire
▪ Auto-implement
▪ Type : integer.

o Location :
▪ Type : varchar (255)
▪ Null : non

o Start_date :
▪ Type : datetime
▪ Null : non

• User
o Id :
▪ Clé primaire

Romain Ricard 20
 ▪ Auto-implement
▪ Type : integer.
▪
o Username :
▪ Unique
▪ Type : varchar (255)
▪ Null : non

o Password :
▪ Type : varchar (255)
▪ Null : non

• Post_category :
o post_id :
▪ Clé primaire
▪ Type : integer.

o category_id :
▪ Clé primaire
▪ Type : integer.
▪ Clé étrangère

Il y a 2 relations, une qui fait la liaison post et post_category et une autre qui fait
category et post_category.

La table post_category permet l’assignement d’une ou plusieurs catégories à un

même post et qu’une catégorie soit assignée à différents posts. C’est donc une
relation n,n et la table post_category est appelée table de jonction.

B. Développement des fonctions

1. Mise en place de la base de données

Pour la création de la base de données je passe directement par du langage sql pas
de terminal, ni d’orm. Une fois satisfait du résultat j’importe le tout sur phpmyadmin.

Sur le rendu final de notre base de données on aura :

Romain Ricard 21
Figure 6 Concepteur phpmyadmin de ma bdd

Romain Ricard 22
 C. L’authentification

Chaque utilisateur étant considéré comme un admin il n’y aura pas de rôle associé à
un utilisateur pour se connecter l’administrateur du site aura un identifiant et un mot
de passe afin de pouvoir accéder aux fonctionnalités de l’application.

Je vais vous détaillez au mieux les étapes de construction de la partie

authentification de mon site :

Tout d’abord je passe par la création de ma route en me rendant dans le dossier

public et le fichier index.php.
Ensuite dans mes vues situées dans le dossier views je crée un dossier auth (pour
authentification) qui va contenir à la fois ma fichier login.php et logout.php
Dans ce fichier login je crée mon formulaire en post et pour cela je dois créer un
modèle qui portera le nom de User.php. J’y met mes propriétés en privé ainsi que
mes getters et setters pour y avoir accès.
Dans ma vue login.php je crée mon nouvel utilisateur et mon nouveau formulaire
avec mon utilisateur ainsi qu’un tableau vide pour la gestion des erreurs.

Je créer mes 2 champs de type input ainsi que mon bouton

Figure 7 views/auth/login.php

Pour le mot de passe je passe par form.php de mon dossier HTML j’ajoute dans ma
méthode input le type pour mettre password et dans mon input j’ajoute le type.

Figure 8 HTML/Form.php

Romain Ricard 23
Le fichier Form.php me permet de faciliter la création de mes formulaires j’y gère la
création des labels et types de champs pour chacun de mes formulaires donc tout
est regroupé ce qui m’évite une redondance du code dans mes vues.

Maintenant on traite les données au-dessus on vérifie si le $_post est vide ou si l’un
des deux post est vide et on y met notre erreur.
Pour se souvenir des données entrées par l’utilisateur on utilise notre setUsername.
Pas nécessaire pour le mot de passe.
On doit démarrer la session, on sauvegarde l’id de l’utilisateur en session

Figure 9 views/auth/login.php

Dans HTML/Form.php : Si error est un tableau alors on fait un imlode de nos error
sinon on indique directement l’erreur.

Figure 10 HTML/Form.php

Romain Ricard 24
On passe par la création d’un UserTable dans notre dossier Table afin de vérifier si
le mot de passe de l’utilisateur et son identifiant son correct.
On prépare notre requête avec une clause where on l’execute puis on récupère
l’enregistrement via le setFetchMode.
Si la variable forbidden est définie alors on affiche le message d’erreur qui sera
indiqué via une alerte.

Figure 11 Table/UserTable.php

Je retourne dans ma vue pour y faire une instance de pdo.

On crée notre usertable.
Mtn on doit trouver l’utilisateur qui correspond au pseudo rentrer par l’utilisateur on
utilise notre findByUsername.
On fait un try catch pour dire qu’on a aucun utilisateur qui correspond, on récupère le
mot de passe étant donné que le password est haché pour vérifier.
Si le mot de passe est bon on doit passer par password_verify il faut que le résultat
soit true.

Puis on redirige vers notre Dashboard admin.

Maintenant on va devoir gérer tout ce qui est session donc on crée à la racine de
notre dossier src un fichier Auth.php pour s’assurer que la session est démarrée si la
session n’est pas démarrée on fait un session_start.

Figure 12 src/Auth.php

On crée un dossier Security dedans il y aura un fichier ForbiddenException pour dire

à l’utilisateur qu’il n’a pas accès à cette page si pas de session en cours

Romain Ricard 25
Pour rediriger vers la bonne url on se rend dans notre Router.php on catch les
forbiddenException et on redirige vers la page login.
Voilà notre partie d’authentification est terminer maintenant on passe par la
déconnexion
On définit notre route de déconnexion en logout dans le public/index.php
Dans le menu du dashboard admin qui se trouve dans layouts/default.php on créer
un lien supplémentaire dans le menu, ce sera un formulaire avec comme action
logout et une méthode post.
A l’intérieur on aura qu’un boutton de type submit.

Dans le fichier des view/auth on crée un fichier logout.php dedans on fait juste un
session_strat session_destroy pour détruire la session et ensuite on redirige vers la
page login.

Romain Ricard 26
 D. Gestion des articles

La gestion des articles consiste à pouvoir lire une liste d’articles mais aussi de créer,
modifier, supprimer un article
Pour cela il faudra auparavant se connecter pour avoir accès au tableau de bord
d’administration.

1. Liste d’articles

Création de la route, puis de la vue on créer un dossier admin puis un dossier post
qui contiendra toutes les vues de nos peintures/articles donc l’index, l’édit, la création
et la suppression.
On crée nos model post.php et category.php qui contiendra nos getters et nos
setters.
Dans notre index on instancie notre pdo, on créer une nouvelle post table avec
l’instance de pdo et on lui demande d’utiliser la méthode findPaginated qui permet de
gérer la pagination de nos articles.

Figure 13 views/admin/post/index.php

On crée une boucle pour aller afficher les différents attributs dont on va avoir besoin
se sera sous forme de table. On passe par htmlentities pour sécuriser le code.

Figure 14 views/admin/post/index.php

Romain Ricard 27
On crée différents boutons pour éditer et supprimer les articles. On y ajoute un peu
de js avec onclick pour faire une vérification si l’utilisateur souhaite vraiment
supprimer. Pour ce qui est de l’action supprimée ce sera un formulaire en post avec
seulement un bouton submit. Ce qui fait que si quelqu’un m’envoie le lien de
suppression ça ne fonctionnera pas.

2. Supprimer un article

Dans mon dossier de vue et mon dossier admin je crée un fichier delete.php.
Je récupère ma pdo, je fais un new postTable et ensuite je fais un delete avec l’id de
l’url de l’article.
Puis une redirection.
Cependant je n’ai pas encore créé ma méthode delete donc je me rends dans mon
Table pour créer cette méthode qui aura comme paramètre l’id qui sera un entier et
on va étendre notre Table dans notre PostTable car certaines méthodes reviendront.
J’écris ma requête sql de DELETE, je sauvegarde la requête dans une variable puis
je l’exécute. Si une suppression ne se passe pas correctement on affiche une erreur.

Figure 15 Table/Table.php

Si la suppression se passe correctement je voudrais un affichage pour l’utilisateur

dans ce cas je retourne dans ma vue delete.php. Je lui indique que si l’url comporte
un delete=1 alors dans ma vue index.php j’affiche une alerte comme quoi la
suppression est ok.

Figure 16 views/admin/post/delete.php

Romain Ricard 28
 3. Création et modification d’article

On crée une route en match qui sera soit en post soit en get qui sera une méthode
créer dans notre Router.php
On récupère l’instance de pdo, puis on crée notre postTable et j’injecte l’instance de
pdo.
On crée un nouvel objet post qui sera vide
On dit que la date du jour se sera la date actuelle.
Il y aura aussi une vérification via Validator, une librairie valitron que j’ai installé avec
composer. Pour chacun des dossiers formulaires type il y a un validator qui lui es
associé pour l’edit et le create post il y a un fichier PostValidator.php ou des règles
nous indique si le champ est requis ou nom, la longueur de celui-ci si c’est une image
et on pourra même crée des nouvelles règles qui nous permettrons de vérifier si un
champ utilise déjà ce nom.

Figure 17 src/Validators/PostValidator.php

On crée une méthode create dans notre postTable qui correspond à peu de chose
prêt à notre méthode update. Une fois la création réussie on redirige vers la page de
listage des articles sinon on affiche le tableau d’erreur.

On crée un nouveau fichier vu _form.php qui contiendra le formulaire à la fois pour

l’édition et la création. Et on fait un require de ce form dans mon edit et mon new.php

Romain Ricard 29
Figure 18 views/admin/post/_form.php

Cependant il nous manque la liste déroulante qui fait la liaison avec nos catégories.
On va dans notre HTML/Form.php et on crée une nouvelle méthode pour notre liste
déroulante qui aura 3 paramètres la clé de mon champ, le nom de mon label et un
tableau d’options qui contiendrait le numéro de la catégorie et le nom de celle
associée. Ce fichier me servira pour tous mes formulaires.
Maintenant sur mon edit.php je dois récupérer la liste des catégories sous le format
clé, valeur. Je fais donc un new CategoryTable pour récupérer sous forme de liste.
Je crée la méthode list dans mon CatégoryTable qui récupère toutes les catégories.
On crée un tableau result où on récupère l’id et et le nom.

Il faut aussi penser à hydrater nos post afin de voir ce qui a été sélectionné par
l’utilisateur dans le cas d’une modification. Pour cela on droit créer une nouvelle
fonction dans model post.php qui récupère les id des catégories. Ensuite dans mon
Form.php on vérifie si l’élément est sélectionné.

Pour faire en sorte qu’un utilisateur ne puisse pas sélectionner une catégorie qui
n’est pas présente en base de données on doit se rendre sur notre PostValidator et
on ajoute la règle subset qui permet justement cette vérification.

Romain Ricard 30
Pour vérifier dans notre edit que sa enregistre bien dans le champ ce qui est présent
en base de données on passe par notre postTable on récupére les informations de
l’article dans la méthode update et en plus le tableau des catégories d’article. On fait
une suppression en post_category en fonction de son post_id et maintenant on
insère les enregistrements toujours en fonction du post_id et category_id.

Figure 19 views/admin/post/edit.php

On crée une nouvelle méthode attachCategories qui gère la catégorie associée à

nos post dans notre PostTable.
On retourne dans notre vue edit.php et on fait un attachCategories avec l’id de
l’article et la liste des catégories. Puis on va dans notre vue new.php après notre
create post on utilise notre methodattachCategories

Figure 20 Table/PostTable.php

Au niveau du rendu final on aura :

Romain Ricard 31
Figure 21 Page d'index d'administration des articles

Romain Ricard 32
VII. Test et Recettage
Dans un premier temps, afin de générer un jeu de données pour les tests j’ai utilisé
faker une librairie open source PHP trouvée sur packagist et ajoutée via composer.
Le but étant de générer un nombre défini d’enregistrement sur chaque table présente
en base de données. Afin d’avoir un rendu visuel sur ce que pourrait donner
l’application lors du déploiement.

Pour cela j’ai créé un dossier command avec un fichier fill.php qui contient les
requêtes d’insert ion en base de donnée pour l’intégralité de mes tables.

Figure 22 fill.php

Pour valider le bon fonctionnement de l’application, j’ai effectué des tests de

fonctionnement sur un environnement test de type wamp sur mon poste fixe.
J’ai aussi fait de nombreux tests en ajoutant diverses librairies présentent sur
symfony comme whoops qui permet d’avoir un meilleur visuel concernant les erreurs
et un historique des fichiers afin de suivre le cheminement qui conduit à l’erreur.
J’y ai aussi installé la librairie var-dumper de symfony qui me permet de faire des
dd()

L’environnement est basé sur les mêmes configurations que le serveur sur lequel il
va être déployé.

Romain Ricard 33
VIII. Déploiement
Je prends un nom de domaine et une offre sur OVH puis une fois l’opération finie je
télécharge Filezilla.

Pour l’environnement de production c’est la même configuration que wamp puisqu’il

s’agit d’un serveur apache qui supporte jusqu’à php 8.0, il y a une interface
phpMyAdmin pour ma base de données mysql.
Actuellement le site est déjà pleinement déployé j’ajoute de nouvelles choses au fur
et à mesure des recherches. Pour l’instant je suis sur l’optimisation du référencement
ainsi que des règles d’accessibilité.

IX. Les backups

Il faut mettre en place des backups que ce soit au niveau de la base de données ou
du code.
Concernant le code le choix est porté sur Github qui permet d’envoyer son code sur
son propre git j’ai décidé de mettre mon code en privé.
Pour ce qui est de la base de données une sauvegarde journalière est faite tous les
matins à 10h 15 une restauration d’une version précédente est possible à tout
moment. De plus je conserve sur mon SSD l’intégralité de la base de données mais
aussi toutes les ressources de mon code.

X. Conclusion
Ce projet m’a permis de découvrir diverses choses comme :
• L’élaboration d’un cahier des charges avec les spécifications techniques et
fonctionnelles
• La création de diverses maquettes
• La création de jeu de données
• La mise en place de backup
• Le déploiement d’une application sur OVH

Je cherche actuellement une entreprise vers Angers ou Cholet composée de

plusieurs développeurs afin de pouvoir évoluer au sein d’une équipe expérimentée
tout en continuant à m’autoformer sur tout ce qui touche au technologie web.

Romain Ricard 34