From acf819737ddff9ccdf27072d7da17969f432d3ff Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Bousqui=C3=A9?= Date: Fri, 18 Sep 2026 15:01:27 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20purge=20PLAN/ROADMAP=20des=20plans=20ab?= =?UTF-8?q?andonn=C3=A9s,=20DRAFT=20vid=C3=A9=20(=C3=89tape=2010=20finie)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit La documentation reflète désormais uniquement ce qui *est* et ce qu'on envisage de faire, pas ce qui aurait pu être (changements d'avis retirés) : ROADMAP.md - 1.2 : remplacé le récit de décision 'transform sur Mesh' (DRAFT Étape 8, déviation) par l'énoncé de l'état actuel : Mesh porte son matériau + sa Geometry CPU partagée, pas de transform (porté par Entity). - Phase 2 réécrite : suppression des 'Arènes complètes' (SlotMap) et de la struct Entity { mesh_id, material_id } contredite par l'Étape 7 (material déplacé sur Mesh) et le choix String IDs ; migration 'handles typés' conservée comme unique pointeur (1.4 / Notes de Décision). - 4.2 : 'Lumières hémisphériques' cochée (déjà dans standard_shader). - Notes de Décision : retiré 'UVs en Phase 4' (caduque, UVs implémentés dès Geometry). PLAN.md - Statut réel condensé et mis à jour jusqu'à l'Étape 10 (textures). - Phase 4 : Textures cochée (faite), Lumières laissée en plan (ROADMAP 4.2). - Check-list pollster dé-obsolétisée ; suppression de la 'Note pour mémoire' décrivant le module-pivot exec.rs qu'on a décidé de ne pas construire. DRAFT.md - Vidé (fin de l'Étape 10) en préparation de l'étape suivante. --- docs/DRAFT.md | 148 ++---------------------------------------------- docs/PLAN.md | 55 +++++++----------- docs/ROADMAP.md | 35 ++++-------- 3 files changed, 33 insertions(+), 205 deletions(-) diff --git a/docs/DRAFT.md b/docs/DRAFT.md index 57a0086..7ef8e34 100644 --- a/docs/DRAFT.md +++ b/docs/DRAFT.md @@ -1,145 +1,5 @@ -# DRAFT — Étape 10 : Textures (Phase 4.1) +# DRAFT — Étape suivante -> 📅 **Rédigé le 2026-09-18.** Plan à valider avant implémentation. -> Source de vérité = code + README.md. Ce document est vidé à la complétion de l'étape. - -## Contexte (état de départ) - -La Phase 4.1 (Textures) du ROADMAP vise à texturer le rendu. État actuel du code : -- **La tuyauterie UV existe déjà** : `Geometry.uvs: Option>` (builder `with_uvs`) - et `Vertex.uv` (location 2, offset 24, stride 56) sont déclarés dans `build_pipeline` et lus - par le shader `VertexInput`. Seul l'**échantillonnage manque**. -- Le shader `standard_shader.wgsl` reçoit l'UV mais ne le transmet pas au fragment et n'échantillonne rien. -- **Aucun type `Texture`**, aucun sampler, aucun bind group de texture. `Material` ne porte pas de texture. -- Architecture bind group : « un seul layout pour tous » (Étape 3) — les groupes `frame @0` - + `object @1` sont posés sur **toutes** les pipelines et bindés à chaque draw (`draw_entity`). - -**Conclusion** : l'UV est prête ; les pièces manquantes sont un type `Texture`, un bind group de -texture (groupe 2) partagé, un échantillonnage dans le shader et le portage sur `Material`. - -## Objectif - -Permettre de texturer un mesh : charger une image → `wgpu::Texture` (+ view + sampler), lier une -texture diffuse à un `Material`, échantillonner dans le shader, **sans casser** le pattern « un seul -layout pour tous ». - -## Décisions (actées le 2026-09-18) - -- **[x] D1 (intégration bind group — « un seul layout pour tous »)** : on ajoute un **3ᵉ bind group** - `@group(2)` (sampler + texture diffuse) posé sur **toutes** les pipelines, avec une **texture - blanche 1×1 de secours (placeholder)** utilisée quand un `Material` n'a pas de texture. Cela - préserve l'unicité du layout (aucune pipeline multiple), donc un seul flux de rendu. *(alternative - écartée : bind group optionnel → casse l'unicité du layout, refactor de toutes les pipelines)*. -- **[x] D2 (échantillonnage inconditionnel)** : le fragment shader échantillonne **toujours** la - texture diffuse ; le placeholder blanc (texel = 1) reproduit exactement le comportement actuel - d'un material sans texture. Donc pas de flag conditionnel → un seul flow de shader. En mode lit, - le **texel remplace la couleur du vertex** (`texel.rgb * (ambient + diffuse)`) ; en unlit, le texel - tel quel. Symétrique du pattern unlit existant. -- **[x] D3 (chargement d'image & format)** : ajouter la dépendance `image` (décodage PNG/JPEG) à - `lib/Cargo.toml` ; upload en `TextureFormat::Rgba8UnormSrgb`, usage `TEXTURE_BINDING | COPY_DST`, - dimension `D2`, `mip_level_count: 1` (**YAGNI** : pas de génération de mipmaps cette étape), - sampler `filter: Linear`, `address_mode: Repeat`. -- **[x] D4 (API et portage)** : nouveau type `Texture` (device + view + sampler). `Material` gagne - `texture: Option>` et détient son **bind group de texture (groupe 2)**, construit - depuis le layout partagé ; sans texture il lie le placeholder. API `Scene` : `add_texture(id, tex)` - et liaison d'une texture à un material. `draw_entity` bind `set_bind_group(2, ...)`. - -## Plan d'implémentation - -### 10.1 — Nouveau type `Texture` + dépendance `image` -- [x] Ajouter `image` à `lib/Cargo.toml` (features `png`, `jpeg`). -- [x] `resources::texture::Texture { texture: wgpu::Texture, view: wgpu::TextureView, sampler: wgpu::Sampler }`. -- [x] `Texture::from_bytes(device, queue, &[u8])` (ou `from_file`) : décode via `image`, remplit un - buffer RGBA et upload via `Queue::write_texture` (D3). -- [x] `Texture::white_placeholder(device, queue)` : 1×1 blanc, pour D1/D2. -- [x] Enregistrer `pub mod texture` dans `resources/mod.rs`. - -### 10.2 — Bind group layout texture (groupe 2) partagé -- [x] `create_uniform_bind_group_layouts` retourne `[frame, object, texture]` (3 layouts) ; `texture` - = `BindingType::Sampler(Filtering)` (binding 0) + `Texture { sample_type: Float, view_dimension: D2 }` - (binding 1), visibilité fragment. -- [x] `build_pipeline` : ajouter le 3ᵉ layout au `PipelineLayoutDescriptor` (l'unicité du layout est - conservée — D1). -- [x] Mettre à jour les destructures `let [frame_layout, object_layout]` (renderer.rs) pour 3 éléments. - -### 10.3 — Shader standard : UV → fragment + échantillonnage -- [x] `VertexOutput` : ajouter `@location(2) uv: vec2` ; `vs_main` écrit `out.uv = input.uv`. -- [x] Déclarer `@group(2) @binding(0) var texture_sampler: sampler;` et - `@group(2) @binding(1) var diffuse_texture: texture_2d;`. -- [x] `fs_main` : `let texel = textureSample(diffuse_texture, texture_sampler, in.uv);` — en lit → - `texel.rgb * (ambient + diffuse)`, en unlit → `texel` (D2). Mettre à jour la doc du module shader. - -### 10.4 — `Material` porte la texture diffuse -- [x] `Material { texture: Option>, texture_bind_group }` ; le constructeur construit le - bind group (groupe 2) depuis le layout partagé, avec placeholder si `None` (D1/D4). -- [x] Méthode `set_texture(...)` qui recrée le bind group si la texture change. -- [x] Le sampler/placeholder partagé est fourni par la lib (une seule instanciation) pour que tout - Material sans texture lie le blanc. - -### 10.5 — API Scene & binding dans `draw_entity` -- [x] Rendre accessible un layout du groupe 2 aux Materials (via `SceneGpu` / cache) pour construire - leurs bind groups. -- [x] Route déclarative `Scene` : `add_texture(id, tex)` et liaison d'une texture par id à un material - (ex. `add_material_texture` ou paramètre de `add_material_shader`). -- [x] `draw_entity` : `pass.set_bind_group(2, material.texture_bind_group, &[])`. -- [x] Vérifier qu'un material *sans* texture continue de fonctionner (placeholder → aucune régression). - -### 10.6 — Exemples + validation -- [x] `cube` : texturer le cube (image PNG embarquée via `include_bytes!` pour rester autonome, - ou un motif procédural RGBA généré en mémoire). -- [x] `simple`/`manual` : pas de régression (placeholder). -- [x] `cargo fmt --all`, `cargo check --workspace` (0 warning), `cargo test --workspace` (vert, tests de - layout uniform + validation WGSL à jour), `cargo doc` (pas de `missing_docs`). -- [x] Exécuter `cube` (faces texturées) et `simple` sans erreur backend. - -## Point d'étape - -- [x] Valider D1–D4 avant implémentation. *(actées le 2026-09-18)* -- [x] Caser 10.1–10.6, validation verte, exemples OK. *(terminé et vérifié le 2026-09-18)* -- [x] Deux commits séparés : `refactor(...)` (10.1–10.5) puis `docs(...)` (10.6) + README/DRAFT. *(refactor : 440f2df ; docs : à finaliser)* -- [x] Rédiger le bilan et ouvrir la suite (Phase 4.2 Éclairage avancé). *(2026-09-18)* - ---- - -## Bilan — Étape 10 : Textures (Phase 4.1) - -**Livrés (commits `refactor` 440f2df puis `docs`) :** -- **10.1** `resources::Texture` — `{ texture, view, sampler }`, format `Rgba8UnormSrgb`, usage - `TEXTURE_BINDING | COPY_DST`, mipmap 1 (YAGNI), sampler `Linear`/`Repeat`. Constructeurs - `from_rgba8`, `from_bytes` (via `image`, features png+jpeg), `from_file`, `white_placeholder` (1×1). - Dépendance `image = "0.25"` ajoutée à `lib/Cargo.toml`. -- **10.2** Layout partagé **groupe 2** (sampler binding 0 + texture binding 1, visibilité fragment). - `build_pipeline` pose les 3 layouts `[frame, object, texture]` sur toutes les pipelines → l'unicité - du layout est conservée (D1). `PipelineCache` détient le layout + le placeholder blanc partagé. -- **10.3** Shader standard : `VertexOutput.uv` (location 2) transmis au fragment ; groupe `@2` - `texture_sampler` (binding 0) + `diffuse_texture` (binding 1). Échantillonnage inconditionnel - (D2) : en lit `base = texel * couleur(vertex)`, en unlit `base = texel`. -- **10.4** `Material.texture: Option>` + `texture_bind_group` construit au constructeur - via le cache (layout partagé + placeholder si aucune texture). -- **10.5** `draw_entity` bind `@group(2)` ; `Scene` : `add_texture` / `get_texture` / - `add_material_texture` ; `init_gpu` prend désormais la `Queue` pour bâtir le placeholder. -- **10.6** Exemple `cube` : nouvelles faces géométriques propres + UV `[0,1]²` par face + texture - damier procédurale (générée en mémoire, pas d'asset externe). - -**Divergence légère vs DRAFT (D2 affiné)** : le plan disait « le texel **remplace** la couleur du -vertex ». À l'implémentation on multiplie (`base = texel.rgb * in.color`) : avec un placeholder blanc -c'est strictement identique pour les materials sans texture, et l'API permet de teinter une texture. -Aucun impact fonctionnel — documenté pour traçabilité. - -**Validation verte** : `cargo fmt --all` propre · `cargo check --workspace` 0 warning · `cargo test ---workspace` 3 tests verts · `cargo doc` sans `missing_docs` (docs manquantes sur le nouveau type -ajoutées). Exécutions réelles de `cube`, `simple`, `manual` sans erreur backend (le fallback -« Shader not found » affiché est le comportement préexistant — répertoire courant ≠ `lib/`). - -**Structure finale en mémoire** (`PipelineCache`) : champ `texture_bind_group_layout` + `placeholder` -(`Arc` blanc 1×1), exposés via les méthodes `texture_bind_group_layout()`, -`placeholder()`, et `texture_bind_group(Option>)` pour créer un groupe 2 depuis une -texture (ou le placeholder). - -**Suite (Phase 4.2 — Éclairage avancé du ROADMAP)** : multi-lumières (directionnelles/ponctuelles), -atténuation, spéculaire Phong raffiné, éventuellement cubemap/Ibl. Ne pas oublier un resize des -textures si on dessert des rendus hors-écran (renvoyé en Phase 4.4 avec le depth). - ---- - -_Fin du DRAFT Étape 10 — étape terminée le 2026-09-18._ +> 📅 **Document vidé le 2026-09-18** (fin de l'Étape 10, Textures — Phase 4.1, bilan archivé +> dans l'historique git). Ce fichier accueillera le plan de l'étape suivante. +> Source de vérité = code + README.md. Ce document est vidé à la complétion de chaque étape. diff --git a/docs/PLAN.md b/docs/PLAN.md index 12829de..5c32773 100644 --- a/docs/PLAN.md +++ b/docs/PLAN.md @@ -11,21 +11,19 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z } Ce plan définit les étapes prioritaires pour finaliser l'architecture actuelle. L'objectif est de rendre l'API intuitive pour l'utilisateur standard tout en conservant la puissance de contrôle pour l'utilisateur avancé. -> **Statut réel (à jour au 2026-09-18).** Ce plan couvre la phase de *consolidation* passée ; la source -> de vérité sur l'état actuel est **README.md** et le code. Depuis la révision du 2026-09-14, l'étape -> **« Scene auto-render »** a été réalisée : le rendu de la `Scene` est **automatisé** en une seule -> passe groupée via `App::render_scene(frame.view())` (appelée par défaut dans `AppHandler::render`), -> et `simple.rs` (API `AppBuilder`, sans `winit`/`wgpu`) déclare un quad rendu automatiquement. -> Le même jour (Étape 3 + 4, 2026-09-16) l'**infrastructure 3D** est en place : bind groups uniformes -> partagés (frame + object), caméra active dans la `Scene` (`Scene::set_camera`/`camera()`) écrite dans -> le buffer frame chaque frame, matrices monde par entité. **Étape 5 (2026-09-17) : MVP 3D atteint** — -> l'exemple `cube` rend un cube unitaire éclairé (Phong) en rotation via `App::render_scene` ; le -> shader `basic` est supprimé, le 2D plat devient la **variante unlit** de `standard` -> (`Renderer::set_unlit` / `app.renderer_mut().set_unlit(true)`). L'**Étape 7 (2026-09-17)** a rattaché -> le `PipelineCache` à la `Scene` et fait référencer son `Material` par chaque `Mesh`. L'**Étape 8 -> (2026-09-18)** a donné à `Mesh` une source de vérité **CPU partagée** (`geometry: Arc`) : -> `Scene::create_mesh(id, Geometry, material)` déclare les meshes depuis une `Geometry` (avec couleurs), -> `Mesh::from_geometry` dérive ses buffers GPU, et les exemples cube/simple/manual utilisent `Geometry`. +> **Statut réel (à jour au 2026-09-18).** La phase de *consolidation* (Phases 1 à 3 de ce plan) est +> **terminée** ; la source de vérité sur l'état actuel est **README.md** et le code. Depuis la révision +> du 2026-09-14, le rendu de la `Scene` est automatisé en une passe groupée +> (`App::render_scene(frame.view())`, appelée par défaut dans `AppHandler::render`) et `simple.rs` +> (API `AppBuilder`, sans `winit`/`wgpu`) déclare un quad rendu automatiquement. Les étapes suivantes +> ont ensuite : posé l'infrastructure 3D (bind groups uniformes frame+object partagés, caméra active, +> matrices monde par entité — Étapes 3+4, 2026-09-16) ; atteint le **MVP 3D Phong** (Étape 5, +> 2026-09-17 : l'exemple `cube` ; le 2D plat = variante **unlit** de `standard` via +> `Renderer::set_unlit`) ; rattaché le `PipelineCache` à la `Scene` et fait référencer son `Material` +> par chaque `Mesh` (Étape 7) ; donné à `Mesh` une source de vérité **CPU partagée** +> (`geometry: Arc`, Étape 8) ; activé un **depth buffer** sur toutes les passes (Étape 9) ; +> et ajouté les **textures diffuses** (Étape 10, 2026-09-18 : `resources::Texture` + bind group @2 + +> `Material.texture`). ## Phase 1 : Finalisation et Nettoyage de l'Existant (Priorité Absolue) @@ -82,8 +80,9 @@ Une fois la plomberie encapsulée, nous devons rendre l'assemblage des objets co Une fois les phases 1 à 3 validées, nous pourrons introduire : -- [ ] **Système de Lumières** : Ajout de buffers d'uniformes dans le PipelineCache. -- [ ] **Textures** : Intégration d'un module de chargement d'images et de BindGroups. +- [ ] **Système de Lumières** : Ajout de buffers d'uniformes dans le PipelineCache *(planifié — ROADMAP 4.2, Éclairage avancé)*. +- [X] **Textures** : Intégration d'un module de chargement d'images et de BindGroups *(fait 2026-09-18, + Étape 10, ROADMAP 4.1 : `resources::Texture`, bind group @2, `Material.texture`)*. - [X] **Caméras** : Gestion des matrices de projection/vue dans la Scene *(fait 2026-09-16, Étape 4.3 — `Scene::set_camera`/`camera()` porte une caméra active ; `render_scene` écrit view/proj/cam_pos réels dans le buffer frame chaque frame, aspect calculé depuis la fenêtre)*. @@ -95,22 +94,6 @@ 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 ? — **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). - -## 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). +- [X] `pollster` est-il isolé de l'utilisateur final ? — résolu : depuis winit 0.30 (2026-09-16), + `pollster` est en `dependencies` de la lib ; le `block_on` de l'init GPU est appelé une seule fois + dans `lib/src/app.rs` (`resumed()`). Les exemples compilent sans le connaître (crates séparées). diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md index 8d7ad29..54c69eb 100644 --- a/docs/ROADMAP.md +++ b/docs/ROADMAP.md @@ -66,16 +66,9 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z } sur `Geometry` (8.5). - [x] Ajouter un mesh de test (cube unitaire) en exemple — **fait** (helper `cube_geometry` dans l'exemple `cube`, Étape 5, 2026-09-17) -> **Note (2026-09-17, DRAFT Étape 7)** : le volet *matériau* de `Mesh` a été fait en Étape 7 : -> `Mesh.material: Option>` (cf. PLAN Phase 2, gestion des matériaux), indépendant de -> la structure `Geometry`. -> -> **Décision **D3** (2026-09-18, DRAFT Étape 8)** : le ROADMAP listait `transform: Transform` sur `Mesh`. -> **Déviation validée : `transform` reste sur `Entity` et n'est PAS ajouté à `Mesh`.** Un mesh est -> **partagé** par plusieurs entités à des transforms différents (modèle instancé, Étape 4/7) : un -> `transform` unique sur `Mesh` casserait ce modèle. L'Étape 8 met donc en œuvre le refactor de -> *stockage CPU* (`Mesh.geometry: Arc` + buffers dérivés) **sans** le champ `transform`. -> *(Implémenté 2026-09-18.)* +> **État (2026-09-18)** : `Mesh` porte son matériau (`mesh.material: Option>`, Étape 7) et +> une source de vérité CPU partagée (`geometry: Arc`, Étape 8). `Mesh` ne porte **pas** de +> `transform` : un même mesh est partagé par plusieurs entités ; le `transform` vit sur `Entity`. ### 1.3 Shader Phong Minimal - [x] Créer `standard_shader.wgsl` (Étape 2, 2026-09-16) : @@ -98,22 +91,15 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z } --- -## Phase 2️⃣ — Système de Ressources complet +## Phase 2️⃣ — Scène enrichie -**Objectif** : Étoffer la Scene avec tous les types de ressources. +**Objectif** : Étoffer la `Scene` au-delà du MVP. -### 2.1 Arènes complètes -- [ ] `SlotMap` -- [ ] `SlotMap` (struct de base) -- [ ] `SlotMap` (struct de base) -- [ ] `SlotMap` pour les entités de la scène +> Les ressources sont, pour le MVP, identifiées par **String IDs** (décision actée — voir Notes de +> Décision). Une migration vers des **handles typés** (slotmap générationnel) reste planifiée quand +> l'éviction/les performances le justifieront (voir 1.4, « reporté »). -### 2.2 Entités & Hiérarchie -- [ ] Struct `Entity { mesh_id: Option, material_id: Option, transform: Transform }` -- [ ] `Scene::add_entity()` → retourne `EntityId` -- [ ] `Scene::iter_entities()` → pour le render loop - -### 2.3 Camera dans la Scene +### 2.1 Camera dans la Scene - [x] Intégrer `Camera` comme ressource de la Scene (Étape 4.3 : `Scene::set_camera` / `camera()`, caméra active unique) - [ ] Permettre plusieurs caméras (actuelle/inactive) et une sélection par identifiant (`scene.set_active_camera(camera_id)`) - [ ] Exposer une caméra orbitale contrôlable (exemple final, Phase 5) @@ -152,8 +138,8 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z } - [x] `Material` supporte une texture diffuse *(Étape 10 : Material.texture + texture_bind_group, placeholder si None)* ### 4.2 Éclairage avancé +- [x] Lumières hémisphériques *(déjà dans le `standard_shader` : mélange hémisphérique, Étape 2)* - [ ] Support multi-lumières (directionnelles, ponctuelles) -- [ ] Lumières hémisphériques - [ ] Shadows (optionnel) ### 4.3 Optimisations @@ -188,7 +174,6 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z } | Décision | Raison | |----------|--------| | **Normals dès Phase 1** | Nécessaires pour le shader Phong ; sans elles, pas d'éclairage | -| **UVs en Phase 4** | Inutiles avant les textures ; on garde `Geometry` simple au départ | | **BBox en Phase 3** | Utile uniquement pour le frustum culling GPU | | **World Matrix CPU → MVP, GPU → Phase 3** | Le MVP est plus simple avec un uniform par mesh ; la migration GPU-driven est progressive | | **String IDs pour le MVP, slotmap reporté** | Le code et le README utilisent des String IDs (simples, sûrs, figés avant la boucle de rendu) ; `ARCHI_ARENES.md` reste la cible "handles typés" pour plus tard. La dépendance `slotmap` a été retirée tant qu'elle est inutilisée |