diff --git a/Correction/ReadMe.md b/Correction/ReadMe.md
index 2057a2e..d732a06 100644
--- a/Correction/ReadMe.md
+++ b/Correction/ReadMe.md
@@ -1,6 +1,259 @@
-# Exemple final de ce à quoi on pourrait arriver
+# 🧠 Architecture & Bonnes Pratiques – MiniJeuxFinal
+
+Le projet **MiniJeuxFinal** a été conçu comme un support pédagogique et technique visant à appliquer des **bonnes pratiques de conception logicielle** en C#.<br/>
+L’objectif principal est d’obtenir un code **maintenable**, **testable** et **facilement extensible**, même pour un projet de petite taille.
+
+
+## 🎯 Objectifs de conception
+
+* Ajouter de **nouveaux jeux** sans modifier l’existant
+* Séparer clairement :
+  * le **cœur métier**
+  * l’**interface utilisateur**
+  * les **dépendances techniques**
+* Favoriser la **testabilité**
+* Éviter le couplage fort et le code rigide
+
+
+## 🧩 Architecture Hexagonale (Ports & Adapters)
+
+Le projet applique une **architecture hexagonale** (aussi appelée *Ports & Adapters*).
+
+Cette architecture vise à **isoler le cœur métier** de toute dépendance externe (UI, console, hasard, etc.).
+
+
+### 🧠 Cœur métier (Domaine)
+
+Le domaine est situé dans le dossier :
+
+```
+Games/
+```
+
+Il contient :
+
+* les règles du jeu
+* les interactions entre joueurs
+* les actions possibles
+
+👉 Le domaine **ne dépend d’aucune implémentation technique**.
+
+
+### 🔌 Ports (Interfaces)
+
+Les **ports** sont définis sous forme d’interfaces et représentent les contrats du domaine.
+
+**Ports métier :**
+* `IGame`
+* `IPlayer`
+* `IAction`
+* `IActionPpc`
+
+**Ports techniques :**
+
+* `IConsole`
+
+👉 Le domaine exprime **ce dont il a besoin**, sans connaître comment c’est fait.
+
+
+### 🔧 Adapters (Implémentations)
+
+Les **adapters** sont les implémentations concrètes des ports.
+
+**Adapters entrants (Driving Adapters) :**
+
+* `GameRunnerConsole`
+
+  * Pilote le jeu depuis l’UI console
+  * Traduit les actions utilisateur vers le domaine
+
+**Adapters sortants (Driven Adapters) :**
+
+* `ConsoleService`
+* `InputActionFactory`
+* `RandomActionFactory`
+
+
+### 🧭 Flux des dépendances
+
+✔ Les dépendances vont toujours **vers le domaine**<br/>
+❌ Le domaine ne dépend jamais des adapters
+
+```
+UI / Infrastructure → Interfaces → Domaine
+```
+
+
+## 🧩 Bonnes pratiques et patterns appliqués
+
+
+### 1. Single Responsibility Principle (SRP)
+
+**Application :**
+
+* Chaque classe a une responsabilité unique :
+  * logique métier
+  * affichage
+  * création d’objets
+  * accès à la console
+
+**Pourquoi :**
+
+* Code plus lisible
+* Maintenance facilitée
+* Changements localisés
+
+
+### 2. Programmation orientée interfaces
+
+**Application :**
+
+* Interfaces génériques (`IGame`, `IPlayer`, `IAction`)
+* Interfaces spécialisées par jeu (`IActionPpc`)
+* Abstractions techniques (`IConsole`)
+
+**Pourquoi :**
+
+* Faible couplage
+* Remplacement facile des implémentations
+* Meilleure extensibilité
+
+
+### 3. Dependency Inversion Principle (DIP)
+
+**Application :**
+
+* Le domaine dépend uniquement d’abstractions
+* Les implémentations concrètes sont injectées via des factories
+
+**Pourquoi :**
+
+* Indépendance technologique
+* Testabilité accrue
+* Code plus robuste
+
+
+### 4. Factory Pattern
+
+**Application :**
+
+* `PierrePapierCiseauxGameFactory` pour créer un jeu complet
+* Factories d’actions (`InputActionFactory`, `RandomActionFactory`)
+
+**Pourquoi :**
+
+* Centralisation de la création d’objets
+* Suppression de la logique d’instanciation du métier
+* Facilite l’évolution
+
+
+### 5. Strategy Pattern
+
+**Application :**
+
+* Chaque action (Pierre, Papier, Ciseaux) est une stratégie distincte
+* Les joueurs utilisent des comportements interchangeables
+
+**Pourquoi :**
+
+* Suppression des `switch` complexes
+* Ajout de nouvelles actions sans modification du code existant
+* Code plus propre et extensible
+
+
+### 6. Open / Closed Principle (OCP)
+
+**Application :**
+
+* Extension par ajout de classes
+* Aucun code existant modifié pour ajouter :
+
+  * un nouveau jeu
+  * une nouvelle action
+
+**Pourquoi :**
+
+* Réduction des risques de régression
+* Code stable sur le long terme
+
+
+### 7. Clean Architecture (approche simplifiée)
+
+**Application :**
+
+* Le domaine ne dépend ni :
+
+  * de l’UI
+  * de la console
+  * du hasard
+
+**Pourquoi :**
+
+* Domaine réutilisable
+* Structure claire
+* Complément naturel de l’architecture hexagonale
+
+
+### 8. Testabilité par design
+
+**Application :**
+
+* Interfaces partout
+* Dépendances abstraites
+* Console simulable
+
+**Pourquoi :**
+
+* Tests unitaires sans UI
+* Scénarios déterministes
+* Meilleure fiabilité du code
+
+
+## 🏁 Conclusion
+
+Même à l’échelle d’un mini-jeu console, cette architecture permet :
+
+* un **code modulaire**
+* une **évolution sans régression**
+* une application concrète des principes **SOLID**
+* une implémentation claire de l’**architecture hexagonale**
+
+👉 *MiniJeuxFinal* constitue une **base saine, extensible et pédagogique** en C#.
+
+---
+
+# 📚 Annexe – Définitions
+
+### Architecture Hexagonale (Ports & Adapters)
+
+Architecture visant à isoler le cœur métier des détails techniques via des interfaces appelées ports, implémentées par des adapters.
+
+### Single Responsibility Principle (SRP)
+
+Une classe ne doit avoir qu’une seule raison de changer.
+
+### Dependency Inversion Principle (DIP)
+
+Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau, mais d’abstractions.
+
+### Open / Closed Principle (OCP)
+
+Une entité logicielle doit être ouverte à l’extension mais fermée à la modification.
+
+### Factory Pattern
+
+Pattern de création qui délègue l’instanciation d’objets à une classe dédiée.
+
+### Strategy Pattern
+
+Pattern comportemental qui encapsule des comportements interchangeables derrière une interface.
+
+### Clean Architecture
+
+Approche architecturale séparant le domaine métier des détails techniques.
+
+---
 
-Cette solution est un aperçu des bonnes pratiques mises en place.
 
 ```
 MiniJeuxFinal/