diff --git a/docs/PLAN.md b/docs/PLAN.md
index 3389287..ebc364c 100644
--- a/docs/PLAN.md
+++ b/docs/PLAN.md
@@ -83,6 +83,22 @@ Une fois les phases 1 à 3 validées, nous pourrons introduire :
   exposée via `Frame::view()`, `render()` dessine la scène automatiquement en une passe via
   `App::render_scene(frame.view())`, la présentation est faite par `App::run`)
 - [X] Les modules sont-ils bien exposés via `lib.rs` ?
-- [X] `pollster` est-il uniquement en dev-dependencies ?
+- [X] `pollster` est-il uniquement en dev-dependencies ? — **obsolète** : depuis la migration
+  winit 0.30 (2026-09-16), `pollster` est en `dependencies` de la lib (le `block_on` d'init GPU
+  est désormais appelé dans le code de la lib, `app.rs`, cf. note pour mémoire ci-dessous).
 
-Ce plan garantit que les fondations sont saines. Une fois la Scene rendue automatiquement par `app.render()`, l'ajout de toute nouvelle fonctionnalité (lumières, textures) deviendra une simple question d'ajout de données dans la structure de scène, sans modification de la boucle de rendu.
+## Note pour mémoire : couplage au runtime async (pollster)
+
+Depuis la migration winit 0.30, la lib embarque un runtime async pour l'init GPU. Le point de
+couplage actuel est **unique** : `pollster::block_on(Context::new(...))` dans `lib/src/app.rs`
+(`resumed()`), plus le macro `#[pollster::main]` dans les exemples (crates séparées, hors lib).
+
+À ce stade (un seul appel), **on ne crée volontairement PAS d'abstraction** : ce serait du
+sur-engineering pour un seul point d'appel. Mais si la lib acquiert d'autres appels async
+(chargements / uploads GPU, etc.), il faudra isoler le runtime derrière un **module-pivot unique**
+(`lib/src/exec.rs`, une fonction `block_on`), seul fichier à modifier pour basculer de pollster
+vers tokio/futures-executor — le reste du code appelant `crate::exec::block_on(...)`.
+
+Rappel : pollster et tokio sont des runtimes indépendants qui coexistent sans conflit dans un
+même binaire ; la seule contre-indication est de faire un `pollster::block_on` **à l'intérieur**
+d'un contexte async tokio (blocage imbriqué / deadlock possible).
diff --git a/docs/tech/ARCHI_APP.md b/docs/tech/ARCHI_APP.md
index 3be65cd..e311fc9 100644
--- a/docs/tech/ARCHI_APP.md
+++ b/docs/tech/ARCHI_APP.md
@@ -72,6 +72,13 @@ pub trait AppHandler {
 - **`update()`** : appelé en premier. L'utilisateur peut modifier librement la scène (transformations, ajout/suppression d'entités). Ces modifications sont synchronisées vers le GPU via un **single buffer** Transform avant la passe de calcul.
 - **`render()`** : appelé après. Il ne sert qu'à injecter du rendu personnalisé (debug, HUD, etc.). La Scene reste immuable : aucune mutation d'état métier.
 
+> **Note pour mémoire (init GPU / runtime async)** : depuis la migration winit 0.30, l'init GPU
+> se fait dans le callback synchrone `resumed()`, donc via `pollster::block_on(Context::new(...))`
+> dans `app.rs`. C'est actuellement le **seul** point de couplage de la lib à un runtime async.
+> On ne crée volontairement pas d'abstraction tant qu'il n'y a qu'un appel ; si la lib acquiert
+> d'autres appels async, isoler le runtime derrière un module-pivot unique (`exec::block_on`),
+> seul fichier à modifier pour basculer vers tokio/futures-executor. Voir PLAN.md (note pour mémoire).
+
 ## 4. Workflow et Cycle de Vie
 
 ### A. Initialisation (Configuration)