diff --git a/README.md b/README.md
index 3228583..9698acb 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,121 @@
+
+# Projet d'Entity FrameWork et Consomation et Développement de services
+
+Notre projet à pour objectif la liaison entre une base de donnée et un client, par l'utilisation d' ``EntityFramework`` et d'une ``API`` C# créé par nous même.
+
+![C#](https://img.shields.io/badge/c%23-%23239120.svg?style=for-the-badge&logo=c-sharp&logoColor=white)
+![JWT](https://img.shields.io/badge/JWT-black?style=for-the-badge&logo=JSON%20web%20tokens)
+![Markdown](https://img.shields.io/badge/markdown-%23000000.svg?style=for-the-badge&logo=markdown&logoColor=white)
+
+> *A noter que seul la v1 est prise en compte, la v2 et v2.2 ne sont presentes uniquement pour prouver notre capacité à versionner*
+
+Ce projet est decoupé en deux parties :
+
+## :alien: Consomation et Développement de services :construction_worker:
+
+
+#### :steam_locomotive: Comment lancer le projet ?
+
+> (Explication...) :construction:
+
+
+#### :checkered_flag: État des livrables : 
+
+:construction:
+> * :heavy_check_mark: Mise en place de toutes les opérations CRUD
+> * :heavy_check_mark: API RESTful (respect des règles de routage, utilisation des bons status code ...)
+> * :heavy_exclamation_mark: Utilisation des fichiers configurations
+> * :heavy_check_mark: Versionnage de l'api (avec versionnage de la doc)
+> * :heavy_check_mark: Logs
+> * :heavy_check_mark: Tests unitaires
+> * :heavy_exclamation_mark: Réalisation du client MAUI et liaison avec l'api
+> * :heavy_check_mark:Liaison avec la base de données
+> * :heavy_check_mark:Filtrage + Pagination des données
+> * :construction: Propreté du code (Vous pouvez vous servir de sonarqube)
+> * :heavy_check_mark: Dockerisation et Hébergement des API (CodeFirst)
+
+> * :heavy_exclamation_mark: Sécurité
+> * :heavy_check_mark: Utilisation SonarQube
+
+[![Build Status](https://codefirst.iut.uca.fr/api/badges/corentin.richard/EntityFramework_ConsoDeServices_TP/status.svg)](https://codefirst.iut.uca.fr/corentin.richard/EntityFramework_ConsoDeServices_TP)
+
+
+
+---
+## :package: Entity FrameWork :construction_worker:
+:construction:
+
+#### :checkered_flag: État des livrables : 
+
+Partie 1 : 
+* Exo1 : :construction:
+    une base de données
+    une table de champion
+    utilisation du client console/mobile
+    requetes CRUD (+ tri, filtrage)
+
+* Exo2 : :heavy_check_mark:
+    UT
+    Base de données stubbée
+    SQLiteInMemory
+
+* Exo3 : :heavy_check_mark:
+    Déploiement EF et tests via code#0
+
+---
+
+Partie 2 :
+* Exo4 : :heavy_check_mark:
+    implémentation des runes et skins (1 table -> pas de relation)
+
+* Exo5 : :heavy_check_mark:
+    Relation entre champion et skin (OneToMany)
+
+* Exo6 : :heavy_check_mark:
+    Relation entre Champion, RunePage et Rune (ManyToMany)
+> La relation entre Rune et RunePage à été simplifiée par manque de temps, il ne s'agit donc pas d'un dictionaire mais d'un OneToMany.
+
+* Exo7 : :heavy_check_mark:
+    mapping entre model et entité (intégration de qualité)
+    (en 1 table et avec relations)
+
+* Exo8 : :heavy_exclamation_mark:
+    Ajouter le paterne UnitOfWork (rollback en cas de probleme sur les transaction)
+
+--- 
+#### Diagramme d'architechture :
+
+![](./docAsset/Diagramme%20d'architecture.jpg)
+Le schéma ci-dessus décris l'architecture finale que doit avoir le projet,  
+
+Tout en haut, la partie client est composé du client MAUI et et du client Console, ceux-ci permettent l'affichage des ressources, l'utilisation de l'architecture et donc de tester si tout le projet fonctionne. Celui-ci utilise le HTTPDataManager qui lui permet d'effectuer les requêtes à l'API afin de récupérer les données. Il hérite de IDataManager et peux donc être remplacé par EFDataManager, court-circuitant ainsi l'API ou par StubLib, n'utilisant pas l'API et l'EF. Le DataManager utilise l'une des extensions mapper pour convertir les objets DTO en Model. 
+> On indique aux client d'utiliser le HttpDataManager :  
+
+    builder.Services.AddScoped<IDataManager,HTTPDataManager>();
+
+En second, la partie API, celle-ci s'occupe de recevoir les requêtes et de renvoyer les objet en conséquent. Dans l'implémentation idéale, l'API utilise l'EFDataManger pour faire appel aux données stockés en base de données. Il hérite lui aussi de IDataManager mais ne peut être remplacé que par le StubLib.Il utilise lui aussi des extensions mapper pour convertir les objets Entity en Model.
+> On indique à l'API d'utiliser le EFDataManager :  
+
+    builder.Services.AddScoped<IDataManager,EFDataManager>();
+
+## Explication de ce qu'on a fait et ce qu'on a pas fait et pourquoi on a priorisé ca plutot que d'autre :
+
+
+
+
+:construction:
+
+## Coordonnées :
+
+``Corentin Richard`` : **[corentin.richard@etu.uca.fr](https://codefirst.iut.uca.fr/git/corentin.richard)**  
+
+``Pierre Ferreira`` : **[pierre.ferreira@etu.uca.fr](https://codefirst.iut.uca.fr/git/pierre.ferreira)**
+
+
+---
+# Sujet principal :
+
+---
 # prepaLoL
 
 ## Diagramme de classes du modèle
diff --git a/docAsset/Diagramme d'architecture.jpg b/docAsset/Diagramme d'architecture.jpg
new file mode 100644
index 0000000..de07a54
Binary files /dev/null and b/docAsset/Diagramme d'architecture.jpg differ