diff --git a/Description_Architecture.md b/Description_Architecture.md
new file mode 100644
index 0000000..66ae7fc
--- /dev/null
+++ b/Description_Architecture.md
@@ -0,0 +1,24 @@
+# Description de l'architecture
+## Vue d'ensemble
+L'architecture de notre application est basée sur l'utilisation d'un modèle et d'une vue seulement.  
+Elle est conçue pour répondre aux besoins des joueurs du jeu Minecraft. Cette solution est composée de 4 projets dont 2 principaux : le Modèle et les Vues (aussi la console et les tests unitaires).  
+  
+Le **Modèle** représente l'ensemble des classes de notre application : nous avons une classe *User* (utilisateur), une classe Conseil, et une classe *Monstre*. Nous utilisons principalement ces classes dans notre applications par l'intermédiaire du projet **Persistance**.  
+Aussi, la classe Conseil est utilisée dans Monstre (Liste de conseil pour chaque monstre), et la classe Monstre dans User (Liste de monstres déjà vus pour tel utilisateur).
+La **Persistance** possède de nombreuses classes : les loaders (XML, JSON, Stub...) qui permettent de charger et de sauvegarder les Users et les Monstres. Elles possèdent le code des différentes fonctions. Nous avons aussi 2 Manager, qui nous permettent de d'appeler par l'intermédiaire de 2 interfaces les fonctions contenues dans les loaders. *(pour plus d'informations, voir la section suivante)*  
+Nous avons aussi différentes fonctions de recherche dans les Manager, qui sont ensuite utilisées dans les Vues et leur code-behind.  
+  
+Les **Vues** sont donc les différentes pages de notre applications. Elles interagissent avec le modèle pour récupérer les données nécessaires à l'affichage, mais aussi pour réagir et répondre aux actions de l'utilisateur. A noter que nous déclarons les 2 Managers avec leur type de loader dans le code-behind de App : cela nous permet d'y accéder dans les autres vues du projet. Nous avons différentes pages ayant des fonctionnalités complètement différentes : la page d'accueil permet à l'utilisateur de sélectionner la méthode de connexion, tandis que la page principale nous permet de très nombreuses fonctionnalités : des interactions avec les bases de données, la recherche de Monstre dans la bd, mais aussi le filtrage de Monstres, l'ajout, la modification, la suppression de Conseils...  
+Nous utilisons le Binding sur nos Managers pour afficher les informations nécessaires dans les vues, en ayant implémenté INotifyPropertyChanged dans les classes que l'on veux "binder".  
+  
+
+## Patrons de conception
+Nous avons utilisé 2 patrons de conception :
+#### La Strategy
+Ce patron nous permet d'utiliser différentes classes de Loader, directement dans le constructeur de Manager. Nous déclarons en fait une interface communes à tous les Loaders, de façon à utiliser celui de notre choix :  
+Nous faisons une **injections de dépendance** dans le constructeur de Manager, de type I.....Manager() (nous avons 2 Manager, donc 2 interfaces aussi).  
+
+#### La façade
+Nous avons aussi utilisé la façade, notamment dans l'utilisation des Managers : en effet, les interfaces I.....Manager() nous permettent de simplifier l'accès aux différentes méthodes de chargement et de sauvegarde des Loaders.  
+
+> N.B : Les dépendances entre les différents projets sont expliquées dans la vue d'ensemble de l'architecture.
\ No newline at end of file