diff --git a/EXPLICATION_form.md b/EXPLICATION_form.md
new file mode 100644
index 0000000..ea807f8
--- /dev/null
+++ b/EXPLICATION_form.md
@@ -0,0 +1,95 @@
+# 📨 À quoi sert vraiment une balise `<form>` ?
+
+Tu as un `<form>` autour de ton formulaire de contact, mais ce qu'il fait « en coulisses » n'est pas forcément clair. Ce fichier explique **à quoi il sert**, puis les deux attributs qui prêtent à confusion : **`action`** et **`method`**.
+
+---
+
+## 1. Le rôle du `<form>` : regrouper et **envoyer** des champs
+
+Un `<form>` est une **enveloppe** autour de plusieurs champs (`<input>`, `<textarea>`…). Son but : permettre à l'utilisateur de **tout envoyer d'un coup**, en un seul geste (le bouton « Envoyer »).
+
+Sans `<form>`, tes champs s'affichent quand même… mais ce ne sont que des cases isolées : il n'y a aucune notion d'« envoi groupé ». Le `<form>`, lui, apporte 3 choses automatiquement :
+
+1. **Il rassemble** toutes les valeurs des champs qu'il contient.
+2. **Il les empaquette** en associant chaque valeur au `name` de son champ.
+3. **Il les envoie** à une adresse, quand on clique sur un bouton `type="submit"`.
+
+> 🔑 **Le détail le plus important : l'attribut `name`.**
+> Seuls les champs qui ont un **`name`** sont envoyés, et c'est ce `name` qui sert d'**étiquette** à la valeur. Dans ton formulaire :
+> ```html
+> <input type="text"  name="prenom"    ...>
+> <input type="email" name="email"     ...>
+> <textarea          name="contacter"></textarea>
+> ```
+> → au moment de l'envoi, le navigateur construit quelque chose comme :
+> `prenom = Mélissa`, `email = melissa@mail.com`, `contacter = ...`
+> Un champ **sans `name`** est tout simplement **ignoré** à l'envoi, même s'il est rempli.
+>
+> 💬 C'est aussi pour ça que `FormData` (Niveau 5, exo 8) lit les champs par leur `name` : tout est lié.
+
+> ⚠️ Rappel utile : pour que l'envoi parte, le bouton doit être **dans** le `<form>` et être un `type="submit"` (un `<button>` sans `type` précisé compte comme submit par défaut).
+
+---
+
+## 2. L'attribut `action` : **OÙ** vont les données
+
+```html
+<form method="get" action="">
+```
+
+`action` indique **l'adresse qui va recevoir** les données — en général un programme **côté serveur** (en PHP, Node, Python…) qui les enregistre, envoie un e-mail, etc.
+
+- `action="https://exemple.com/contact"` → les données partent vers cette adresse.
+- `action=""` (vide, comme chez toi) → elles sont envoyées à **la page actuelle** (la même URL).
+
+> 💡 **Important pour ton cas :** vous n'avez **pas encore de serveur** derrière. Donc `action=""` ne mène nulle part d'utile : la page se contente de se recharger. C'est **normal à ce stade**, et c'est exactement pour ça que tu interceptes l'envoi en **JavaScript** (avec `addEventListener("submit", ...)` et `preventDefault()`) pour faire toi-même quelque chose d'utile (vérifier le message, afficher le prénom dans une alerte…). Tu l'as déjà fait — c'est cette logique-là qui « remplace » le serveur pour l'instant.
+
+---
+
+## 3. L'attribut `method` : **COMMENT** les données sont envoyées
+
+Il existe deux façons principales d'envoyer un formulaire : **GET** et **POST**.
+
+### `method="get"` (ce que tu utilises)
+Les données sont **collées dans l'URL**, après un point d'interrogation :
+```
+contact.html?prenom=Mélissa&email=melissa@mail.com&contacter=Bonjour...
+```
+- ✅ Visible dans la barre d'adresse → on peut mettre la page en favori, la partager, la recharger.
+- ❌ Tout est visible (à éviter pour un mot de passe), et la longueur est limitée.
+- 👉 Idéal pour **demander / rechercher** des infos (un moteur de recherche utilise GET).
+
+### `method="post"`
+Les données sont envoyées dans le **corps** de la requête, **pas** dans l'URL.
+- ✅ N'apparaît pas dans la barre d'adresse, pas de limite pratique de taille.
+- 👉 Idéal pour **envoyer / créer / modifier** quelque chose : un message, une inscription…
+
+> 💡 **La règle simple :**
+> - **GET** = « je **demande** des infos » (recherche, filtre, consultation).
+> - **POST** = « j'**envoie / je modifie** des infos » (formulaire de contact, inscription).
+> Pour un formulaire de **contact** où l'on **envoie un message**, `method="post"` serait en fait **plus adapté** que `get`. Essaie de le passer en `post` et regarde la différence avec l'expérience ci-dessous. 🙂
+
+---
+
+## 🔬 Une petite expérience pour bien voir la différence
+
+1. Garde ton `method="get"` actuel. Remplis les champs, clique « Envoyer », et **regarde la barre d'adresse** : tu verras tes valeurs apparaître après le `?` (`?prenom=...&email=...`).
+2. Passe maintenant en `method="post"`, recommence : les valeurs **disparaissent** de l'URL — elles voyagent « cachées ».
+
+Ça rend très concret ce que veulent dire GET (dans l'URL) et POST (hors de l'URL). C'est aussi pour ça que `name` est essentiel : sans lui, rien n'apparaît dans l'URL, car le navigateur ne sait pas comment étiqueter la valeur.
+
+> 🔎 Astuce : pour faire l'expérience proprement, **désactive temporairement** ton `preventDefault()` dans le JS — sinon il empêche justement l'envoi par défaut, et tu ne verras pas l'URL changer.
+
+---
+
+## 📝 Le résumé en une carte
+
+| Élément | À quoi ça sert |
+|---|---|
+| `<form>` | enveloppe qui **regroupe et envoie** les champs d'un coup |
+| `name` (sur chaque champ) | l'**étiquette** de la valeur — sans lui, le champ n'est **pas** envoyé |
+| `type="submit"` (bouton) | **déclenche** l'envoi |
+| `action` | **OÙ** vont les données (l'adresse du serveur ; `""` = la même page) |
+| `method` | **COMMENT** : `get` (dans l'URL, pour demander) / `post` (caché, pour envoyer) |
+
+> 🧭 Tant qu'il n'y a pas de serveur, retiens surtout : le `<form>` **structure** ta saisie, et c'est ton **JavaScript** qui décide quoi en faire à l'envoi. `action`/`method` deviendront vraiment utiles le jour où il y aura un serveur pour recevoir les données.