diff --git a/doc/adr/0002-utiliser-nx-pour-simplifier-la-gestion-des-projets-au-sein-du-monorepo.md b/doc/adr/0002-nx-monorepo.md
similarity index 100%
rename from doc/adr/0002-utiliser-nx-pour-simplifier-la-gestion-des-projets-au-sein-du-monorepo.md
rename to doc/adr/0002-nx-monorepo.md
diff --git a/doc/adr/0003-convention-d-architecture-des-projets-typescript.md b/doc/adr/0003-conventions-de-code.md
similarity index 70%
rename from doc/adr/0003-convention-d-architecture-des-projets-typescript.md
rename to doc/adr/0003-conventions-de-code.md
index 98fd48890f..a171a42236 100644
--- a/doc/adr/0003-convention-d-architecture-des-projets-typescript.md
+++ b/doc/adr/0003-conventions-de-code.md
@@ -1,16 +1,16 @@
-# 3. Convention d'architecture des projets Typescript
+# 3. Conventions de code et d'architecture
 
 Date: 2024-10-01
 
-## Status
+## Statut
 
-Proposed
+Accepted
 
-## Context
+## Contexte
 
 Afin d'améliorer la lisibilité, la cohérence et la maintenabilité de notre codebase, il parait nécessaire d'adopter une convention de nommage pour nos projets, fichiers et dossiers au sein du monorepo. Cette convention vise à standardiser les pratiques et à faciliter la navigation et la compréhension du code par tous les membres de l'équipe.
 
-## Decision
+## Décision
 
 Les conventions de nommage et d'architecture choisies suivent les standards par défaut Typescript, ESLint, Node, Next.js, et Nest.js.
 
@@ -27,47 +27,99 @@ Les conventions de nommage et d'architecture choisies suivent les standards par
 
 - **`kebab-case` pour les noms de fichiers et dossiers**
 
-  Exemple : `src/app/plan-actions/plan-actions.tsx`
-
-- **Organisation des dossiers d'abord par domaine → puis scope → puis layer technique**
-
-  Exemple : `src/indicateurs/models/indicateur.schema.ts`
-
-  Exemple : `src/plan-actions/shared/models/fiche-action.schema.ts`
-
-  Exemple : `src/app/plan-actions/fiche-actions/views/fiche-action.card.tsx`
+  Exemple : `src/app/plans/plan-actions.tsx`
+
+- **Organisation des dossiers d'abord par domaine → puis scope [→ puis feature] [→ puis layer technique]**
+
+  Exemple côté backend :
+
+  ```
+  src
+  └ plans
+    └ fiches
+    · └ count-by-statut
+    · · └ count-by-statut.request.ts
+    · · └ count-by-statut.response.ts
+    · · └ count-by-statut.router.ts
+    · · └ count-by-statut.router.e2e-test.ts
+    · · └ count-by-statut.service.ts
+    · └ update
+    · · └ update.controller.ts
+    · · └ update.request.ts
+    · · └ update.service.ts
+    · └ shared
+    ·   └ fiche-action.table.ts
+    ·   └ fiche-action-referent.table.ts
+    └ shared
+      └ models
+        └ thematique.table.ts
+        └ structure-tag.table.ts
+  ```
+
+  Exemple côté frontend :
+
+  ```
+  src
+  └ plans
+    └ toutes-les-fiches
+    · └ views
+    ·   └ fiche-action.list.tsx
+    ·   └ fiche-action.list-item.tsx
+    ·   └ fiche-action.card.tsx
+    ·   └ fiche-action.card.stories.tsx
+    └ shared
+      └ hooks
+        └ use-create-fiche-action.ts
+        └ use-export-fiche-action.ts
+  ```
 
 - **Suffix des fichiers avec son "type"**
 
-  Exemple type UI : `fiche-action.card.tsx`, `fiche-action.list.tsx`, `fiche-action.list-item.tsx`
+  Exemple type UI :
+
+  - `fiche-action.card.tsx`
+  - `fiche-action.list.tsx`
+  - `fiche-action.list-item.tsx`
 
 - **`index.ts` au niveau des sous-scopes**, si besoin, pour rassembler tous les exports associés et simplifier les imports.
 
-  Exemple : `src/plan-actions/fiche-actions/index.ts`
+  Exemple : `src/plans/fiches/index.ts`
 
-  → résultat à l'import : `import { FicheAction } from '@tet/api/fiche-actions'`
+  → résultat à l'import : `import { FicheAction } from '@tet/api/plans/fiches'`
 
 ### Les domaines métiers Territoires en Transitions
 
 Les domaines correspondent aux principaux contextes métiers de la plateforme Territoires en Transitions.
 
-Voici les domaines définis actuellement :
+Voici les domaines et sous-scopes définis actuellement :
 
 1. `utilisateurs`
 2. `collectivites`
+   - `membres`
 3. `referentiels`
+   - `scores`
+     - `personnalisations`
+     - `snapshots`
+   - `evaluations`
+     - `audits`
+     - `labelisations`
 4. `indicateurs`
-5. `plan-actions`
-6. `impact-actions`
+   - `trajectoires`
+5. `plans`
+   - `plans`
+   - `fiches`
+   - `paniers`
+   - `modeles`
+6. `shared`
 
-Les domaines définis doivent rester restreints et (quasi) figés.
+Les domaines et scopes définis doivent rester restreints et (quasi) figés.
 
 L'ajout exceptionnel d'un nouveau domaine ne peut se faire qu'après validation auprès de l'ensemble de l'équipe.
 
 #### Exemples d'entités au sein de ces domaines
 
 ```
-plan-actions
+plans
   → plan-action
   → fiche-action
 
@@ -75,6 +127,10 @@ indicateurs
   → definition
   → valeur
   → categorie
+
+shared
+  → thematiques
+  → pilotes
 ```
 
 ### Les "layers" et "types" techniques
@@ -106,7 +162,7 @@ Exemples plus granulaires, si pertinent :
 - `views` : couche des composants UI
 - `hooks` : couche de logique UI
 
-## Consequences
+## Conséquences
 
 1.  Standards par défaut
 
@@ -124,7 +180,7 @@ Exemples plus granulaires, si pertinent :
 
     → [Lien plugin VSCode](https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig)
 
-## Useful links
+## Références
 
 - Inspirations autour du concept d'architecture hexagonale / clean code