diff --git a/dossier de projet/main.md b/dossier de projet/main.md
index 29983b8..fb3fb6b 100644
--- a/dossier de projet/main.md	
+++ b/dossier de projet/main.md	
@@ -227,7 +227,7 @@ Pour la conception de notre wireframe ainsi que la maquette de l’application,
 
 ## L'architecture du projet
 
-![Schéma de l'application](images/schema.jpg)
+![Schéma de l'application](images/schema.jpg){width=70%}
 
 ## Technologies utilisées
 
@@ -265,6 +265,8 @@ Pour la conception de notre wireframe ainsi que la maquette de l’application,
 
 La première chose que nous avons fait, c’était de décider quel type de location nous avions envie de faire, et comment on voulait s’organiser. Comme mentionné ci-dessus, nous avons tout d’abord créé un dossier Google Drive pour centraliser toute information pertinente. Ensuite, nous avons créé un document brainstorming pour nos premières idées pour les technologies que nous pensions utiliser afin de pouvoir créer le projet nécessaire. Afin de travailler sur la Merise et les diagrammes, nous avons utilisé Miro, un plateforme de collaboration numérique qui permet de créer des diagrammes entre autres.
 
+### Modèle Conceptuel de Données
+
 En faisant notre brainstorming, nous avons retenu ces choses clés :
 
  * Un utilisateur se connecte à une session.
@@ -283,17 +285,27 @@ Avec ceci, on a pu créer une phrase qui résume nos idées, et on peut créer l
 
 On a aussi fait les maximalités (chiffres en bleu dans notre diagramme). Cela nous a permis de voir rapidement que la relation entre réservation et matérial allait avoir un lien Many to Many, alors pour notre MLD, nous avons mis un tableau intermédiaire afin de mieux gérer ce lien.
 
+---
+\newpage
+
+### Modèle Logique de Données
+
 Nous progressons vers le Modèle Logique de Données, une étape plus concrète dans la définition de la base de données. Comme mentionné ci-dessus, on peut voir qu'il est nécessaire de créer un tableau intermédiaire entre Réservation et Material, qu’on a décidé d’appeler reserved_material, afin d’éviter une relation Many to Many. À cause de cela, on voit qu’on a deux attributs qui sont des foreign keys dans ce tableau, alors que dans d’autres comme Reservation, on a une clé étrangère pour lier les deux entités.
 
 ![Le Modèle Logique de Données](images/MLD.jpg){width=70%}
 
+---
+\newpage
+
+### Modèle Physique de Données
+
 Après avoir créé le modèle logique de données, nous avons procédé à créer le modèle physique de données. Cette étape est particulièrement importante car cela va nous aider à décider comment on va créer notre base de données. On peut déjà voir quels attributs sont les clés étrangères dans le MCD, comme ils sont en verts, mais on le précise également dans le MPD en mettant FK (foreign key) en vert.
 
 ![Le Modèle Physique de Données](images/MPD.jpg){width=70%}
 
 L’information vraiment pertinente dans le MPD qu’on ne trouve pas dans les autres modèles, c’est le type de données pour chaque objet. La plupart sont des VARCHAR, mais par exemple dans notre entité session, cart sera du JSON. Une autre chose qui change c’est que la plupart de nos ids sont du varchar, car on prévoit d’utiliser UUID, sauf dans le cas de l’id de catégorie, où nous avons prévu de faire des simples integers qui vont s’auto incrémenter.
 
----
+\newpage
 
 ## Unified Modeling Language
 
@@ -367,6 +379,7 @@ Un admin, cependant, a des droits qu’un client n’a pas. Il peut créer, mett
 ![Le Diagramme de cas d'utilisation](images/use case diagram.jpg){width=70%}
 
 ---
+\newpage
 
 ### Diagramme de séquence
 
@@ -374,7 +387,7 @@ Le dernier diagramme UML que nous avons créé, c’était un diagramme de séqu
 
 ![Le Diagramme de séquence](images/sequence diagram.jpg){width=70%}
 
----
+\newpage
 
 ## Maquettes et enchaînement des maquettes