diff --git a/MiniJeux/ReadMe.md b/MiniJeux/ReadMe.md
index d6f2745..49bd8f7 100644
--- a/MiniJeux/ReadMe.md
+++ b/MiniJeux/ReadMe.md
@@ -1,5 +1,12 @@
 # But du jeu
 
+Après avoir découvert le fonctionnement de `MiniJeuBourin`, nous allons progressivement améliorer notre code. <br/>
+Nous commencerons par un refactoring, puis nous apprendrons à écrire des tests en utilisant la méthode TDD (Test Driven Development).<br/>
+Au fil de cette évolution, nous ajouterons de nouvelles interfaces, des classes, ainsi qu’une factory pour mieux organiser la création d’objets.<br/>
+Nous utiliserons également des mocks pour isoler certaines parties du code lors des tests.<br/>
+L’objectif final est de comprendre et pratiquer en profondeur le principe de polymorphisme.
+
+
 ## 1. Utiliser le projet MiniJeuBourin pour:
 
 * Créer une interface (IActionPpc) commune pour les `actions` (pierre, papier, ciseaux) (Name, bool ToWin(other))
@@ -18,4 +25,38 @@
 * Ajouter une interface commune pour tous les jeux (IGame (Name, Start, Stop))
 * Ajouter une classe `PierrePapierCiseaux` à la solution en TDD en implémentant `IGame`.
 * Ajouter le jeu *LePendu* à la solution en TDD en implémentant `IGame`.
-* Création d'un menu pour séléctionner le jeu (doit etre auto !)
\ No newline at end of file
+* Création d'un menu pour séléctionner le jeu (doit etre auto !)
+
+Bien sûr ! Voici une **annexe pédagogique** contenant la définition de tous les mots-clés mentionnés.
+
+---
+
+# **Annexe — Définitions des mots-clés**
+
+* **Refactoring**
+  * Le refactoring consiste à **améliorer la structure interne du code** sans changer son comportement.  
+Objectif : rendre le code plus clair, plus simple à maintenir et plus évolutif.
+* **TDD (Test Driven Development)**
+  * Méthode de développement où l’on écrit **d’abord les tests**, puis le code qui permet de les faire passer.
+    * Cycle classique :
+      1. **Red** – écrire un test qui échoue
+      2. **Green** – écrire le code minimum pour le faire réussir
+      3. **Refactor** – améliorer le code tout en gardant les tests au vert
+* **Interface**
+  * Une interface définit **un contrat**, c’est-à-dire une liste de méthodes que les classes doivent implémenter.  
+Objectif : garantir qu’un groupe de classes offre les mêmes fonctionnalités, tout en pouvant avoir des comportements différents.
+* **Classe**
+  * Une classe est un **plan de construction** pour créer des objets.  
+Elle regroupe des données (attributs) et des comportements (méthodes).
+* **Factory**
+  * Une *factory* (ou *factory pattern*) est un modèle de conception permettant de **centraliser la création d’objets**.  
+Objectif : éviter que le reste du code sache *comment* les objets sont construits, ce qui facilite leur remplacement ou leur évolution.
+* **Mock**
+  * Un mock est un **faux objet** utilisé dans les tests pour simuler le comportement d’un objet réel.  
+    * Objectif :
+      1. isoler une partie du code
+      2. éviter les dépendances lourdes (base de données, API, fichiers…)
+      3. tester uniquement ce qui doit l’être
+* **Polymorphisme**
+  * Principe fondamental de la programmation orientée objet qui permet à **différentes classes** d’être utilisées **comme si elles étaient du même type**, grâce à une interface ou une classe mère commune.
+    * Objectif : écrire du code flexible capable de fonctionner avec plusieurs implémentations différentes.