diff --git a/README.md b/README.md
index c3f3445..4d8db74 100755
--- a/README.md
+++ b/README.md
@@ -113,6 +113,12 @@ Cela concerne toutes les routes à l'exception de `/login`. Il faut passer un `H
 X-Token: <token>
 ```
 
+> [!NOTE]
+> Une fois connecté, le vrai site continue d'envoyer un second en-tête,
+> `2FA-Token` (voir [Concernant la connexion (QCM)](#login)), sur les requêtes
+> authentifiées classiques, en plus de `X-Token`. Pas vérifié si l'API le
+> rend strictement obligatoire une fois le login terminé, mais ça ne coûte
+> rien de toujours renvoyer la dernière valeur reçue.
 
 ### Codes erreur
 
@@ -215,6 +221,18 @@ __GET__ `/v3/login.awp?gtk=1&v=4.75.0`
 
 Récupérer la valeur de ce cookies et le passer dans le post de login en header "X-Gtk".
 
+> [!WARNING]
+> Cette réponse pose **deux** `Set-Cookie`, pas un seul : `GTK` (documenté
+> ci-dessus) et un second, `httponly`, au nom opaque qui change à chaque
+> appel. Un client qui ne garde que la valeur `GTK` et ignore ce second
+> cookie voit son login **dégradé en `505` "identifiant et/ou mot de passe
+> invalide" même avec les bons identifiants**, au lieu du `250` attendu
+> (QCM demandé) — vraisemblablement une défense anti-bot. Un vrai navigateur
+> le renvoie automatiquement sans intervention JS ; un client HTTP doit donc
+> garder un petit pot à cookies pour ce couple GET+POST et renvoyer tout ce
+> qui a été reçu, pas seulement extraire `GTK`. Vérifié par capture réseau du
+> vrai site le 31/08/2026.
+
 __POST__ `/v3/login.awp?v=4.75.0`
 
 Data en body :
@@ -222,11 +240,18 @@ Data en body :
 {
   "identifiant": "Username",
   "motdepasse": "Password",
-  "isRelogin": false,
+  "isReLogin": false,
   "uuid": ""
 }
 ```
 
+> [!NOTE]
+> Le champ s'appelle `isReLogin` (L majuscule), pas `isRelogin` : une vraie
+> requête du site (31/08/2026) l'écrit ainsi même pour ce premier login, qui
+> n'est pourtant pas un "relogin". Pas vérifié si la casse fait une
+> différence côté serveur (ASP.NET est généralement insensible à la casse
+> des propriétés JSON), mais autant coller au vrai trafic.
+
 Différents exemples de réponses complètes. Elles suivent le modèle de réponse donné dans la référence.
 
 <details>
@@ -283,6 +308,16 @@ Différents exemples de réponses complètes. Elles suivent le modèle de répon
 > [!NOTE] 
 > **Gardez bien le token mis dans la réponse lors de votre tentative de connexion !**
 
+> [!WARNING]
+> La réponse au login qui renvoie ce `250` porte aussi un en-tête
+> `2FA-Token` (un UUID), séparé du `token` du corps JSON. C'est **cet
+> en-tête**, pas `X-Token`, qu'il faut renvoyer sur les deux appels
+> `doubleauth.awp` ci-dessous — `X-Token` n'est ni requis ni renvoyé par le
+> serveur à ce stade. Chaque réponse de l'enchaînement (login, `doubleauth`
+> `verbe=get`, `doubleauth` `verbe=post`) porte à son tour un nouvel en-tête
+> `2FA-Token` : le récupérer et le renvoyer à l'appel suivant jusqu'au login
+> final. Vérifié par capture réseau du vrai site le 31/08/2026.
+
  __GET__ `/v3/connexion/doubleauth.awp`
 
  Permet de récupérer le QCM (question et réponses) afin de pouvoir se connecter.
@@ -343,17 +378,27 @@ Après tout cela, vous devez refaire une requête login, en y incluant cette foi
     "identifiant": "<identifiant>",
     "motdepasse": "<mot de passe>",
     "isReLogin": false,
+    "cn": "<cn>",
+    "cv": "<cv>",
     "uuid": "",
     "fa": [
         {
             "cn": "<cn>",
-            "cv": "<cv>"
+            "cv": "<cv>",
+            "uniq": false
         }
     ]
 }
 ```
 Et voilà, vous avez enfin votre token valide, prêt à être utilisé !
 
+> [!NOTE]
+> Vu dans une vraie requête (31/08/2026) : `cn`/`cv` apparaissent à la fois
+> en racine du corps et dans `fa[]`, et chaque élément de `fa[]` porte en
+> plus `"uniq": false`. Pas vérifié si les deux emplacements sont vraiment
+> nécessaires ou si le site en fait juste plus qu'il ne faudrait, mais
+> reproduire cette forme exacte fonctionne.
+
 > [!NOTE]
 > Note : Les objets "cn" et "cv" ne sont pas à usage unique et peuvent être stockés pour être réutilisés plus tard