diff --git a/docs/adr/0002-mot-de-passe-pour-heat.md b/docs/adr/0002-mot-de-passe-pour-heat.md
index 1070827..ca15c30 100644
--- a/docs/adr/0002-mot-de-passe-pour-heat.md
+++ b/docs/adr/0002-mot-de-passe-pour-heat.md
@@ -41,6 +41,19 @@ temporaire avec `auth_type: password`, `openstack stack create --wait` →
 `CREATE_COMPLETE`. Confirmé avec Adam (choix : « mot de passe classique pour
 `paillasse-service` ») avant d'appliquer en dur.
 
+**Vérifié aussi (2026-10-08, à la question d'Adam) : `--unrestricted` ne
+change rien.** Une application credential créée avec
+`openstack application credential create ... --unrestricted` échoue
+exactement pareil (`heat-engine.log` : même trace, même
+`Forbidden: Delegated tokens cannot manage trusts`, HTTP 403). `--unrestricted`
+lève seulement l'interdiction qu'a une application credential de créer ou
+supprimer *d'autres* application credentials et trusts en tant qu'action
+demandée explicitement par l'appelant — pas l'interdiction, plus profonde,
+qu'a Keystone de délivrer un *nouveau* trust à partir d'un jeton qui est
+lui-même issu d'une délégation. C'est cette seconde règle que Heat déclenche
+(il crée le trust lui-même, côté serveur, pour pouvoir agir plus tard au nom
+de l'appelant) : aucune option d'application credential ne la contourne.
+
 Changements :
 
 - `/etc/kolla/clouds-paillasse.yaml` : `auth_type: password` (mot de passe